Psychofox a écrit 10742 commentaires

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.

De toute façon tu fais du logiciel libre non ? Si tu fournis les sources tout le monde peut compiler et installer ton appli.

Ben voilà tout le monde est content.

Ta remarque serait pertinente s'il existait d'autres critères disponibles pour faire le tri. Dans le cas des stations services je ne vois pas quel autre critère tu peux donner étant donné qu'on n'a aucune visibilité sur la qualité du carburant proposé, que l'origine du pétrol utilisé peut fluctuer, que le produit raffiné sera de toute façon mélangé et que les différentes sociétés pétrolières fonctionnent à peu près de la même façon (donc zéro critère éthique possible).

Bref l'état offre un service qui semble demandé et apprécié par les citoyens car le prix du carburant a une incidence directe sur leur vie. Il n'y a rien de choquant ni d'idéologique là-dedans.

« Dans les faits, les flics ne débarquent pas en pleine nuit chez n'importe qui, en cassant tout, et en se barrant comme ça. Pour le coup, ils n'ont quand même pas que ça à faire. »

Résumé : le RAID perquisitionne un appart à 4h30 du mat, blesse un des 4 enfants à coup de fusil à pompe, ligote la famille et retourne l'appart, le tout cagoulé, puis s'aperçoit au bout d'une heure qu'ils se sont trompé de porte… mais soyons honnête : après 7 mois l'avocat « se dit confiant quant à une perspective d’indemnisation »…

Je ne vois pas le rapport. Dans le post précédent quelqu'un te dit que la police ne s'amuse pas à perquisitionner tout un chacun sans raison et pour le plaisir. Là tu cite l'exemple d'une erreur de porte. C'est certe franchement navrant mais c'est aussi complètement hors-sujet comme exemple. Quelque soit les garde-fous il y'a toujours une possibilité d'erreur.

La disposition ne fait pas tout, la prise en charge de l'OS est importante. Si Microsoft continue à s'évertuer à ce que windows ne soit pas prêt pour le desktop on ne s'en sortira jamais.

J'utilise la touche avec le logo d'une société américaine pour cela.

Je pensais à la plus ancienne LTS supportée en fait.

Au contraire je pense que la problématique est différente si tu tapes sur des trucs utilisés dans le monde professionnel sur des serveurs de prod (bien que la tendance actuelle tend rarement à recompiler ses binaires soi-même) ou un truc comme les bibliothèques de jeux vidéos qui va viser un public dont les versions des distribs seront mises à jours plus souvent.

Pour une question de "portabilité" je me baserai sur la version la plus basse utilisée par les différentes distros qui sont en support long terme et qui sont encore activement supportées.

Tant chez ubuntu que chez redhat/Centos c'est du 2.8.12. Après tu ne seras peut-être pas obligé d'attendre 2020 (fin de la phase production 3 de redhat6) pour passer à une version supérieure. Après tout cmake c'est fait essenctiellement pour construire des packages donc ça n'a rien à faire sur des machines de production et c'est pas comme si c'était dur d'installer une autre version de cmake et de la mettre dans son path avant un build.

Après je n'ai aucune idée du type de projets sur lesquels tu travaille ni quel est le public destiné.

Ouais bon après c'est un éternel débat. Est-ce que c'est au rôle de la distrib ou l'installeur d'éduquer l'utilisateur où est-ce à lui d'aller chercher l'info…