Difficile de ne pas avoir A = B + C plutôt que A = B - C… Ce genre de bogue n'est pas toujours évident à trouver. Ceci dis, la dernière norme Ada (2012) met en place les 'Type invariants' (http://www.ada2012.org/) qui permet d'éviter un certain d'erreur bête de ce genre.
Il me semble avoir entendu lors d'un exposé que la ligne 1 du métro a été automatisé en Esterel et qu'il n'a été trouvé aucun bogue. Cela semble trop beau pour être vrai à 100% mais je ne connais personne en interne pour confirmer / infirmer et je n'y connait rien en Esterel ;-)
Pour aller dans ton sens, la première version d'Ada est 83 suite aux premières étapes de sa création en 74 ! Ada est arrivé bien après de nombreux succès aéronautiques et spatiaux. D'ailleurs, les deux plus grosses catastrophes que sont les explosions des deux navettes ont lieu sous Ada mais celui-ci n'y était pour rien ;-)
Normalement, winbind gère l'unicité des UID entre plusieurs serveurs sinon ton projet est mort et il ne faut pas faire de NFS… mais du pam_mount via SMB.
Et puis on fait trop confiance au numérique de nos jours. La tour Eiffel n'a pas été calculé par ordinateur. La fusée Saturn V n'ont plus… On est capable de plein de bonne chose sans CPU.
D'un autre coté, le CPU nous donne la cotation boursière et les micro-transactions, la gouvernance sous l'emprise des INDEX de toute sorte… et la planète rougit !
Bref, les langages de haut niveau sont très bien mais ont aussi des travers ;-)
Je n'ai pas l'impression de me contredir. Certes CAP_NET_BIND_SERVICE permet d'avoir un serveur qui regarde sous les ports < 1024… Certes il y a plein de CAP intéressante. Mais en pratique et je l'avais lu quelques parts (LWN ?), les développeurs du noyau ne posent dans le code que quelques CAP_ du coup, le principe des CAP_ fait qu'il est peu utilisé…
La ligne de commande que j'ai donné n'est pas parfaite mais j'ai regardé avant sur pas mal de ligne et globalement, l'erreur final n'est pas si grande. Fait un "grep CAP_" dans les sources et tu verras par toi même… Les chiffres sont là et il y a malheureusement/effectivement quelques CAP fourre-tout qui ne doivent pas être loin du bit suid en pratique…
Je me suis amusé à faire la commande ack '\bCAP_' | perl -p -e 's/.*\b(CAP_[A-Z_]+).*$/$1/;' | sort | uniq -c | sort -n sur les sources de mon noyau. Cela ne donne pas des stats précises au centième mais un bon indicateur.
Je n'ai pas mis toutes les CAP qui sortent moins de 10 fois et qui sont en nombre très importantes… (Il y en a même pas mal qui ne sorte qu'une fois).
Bilan : la bonne idée s'est transformée en quelques CAP_SYSADMIN, 4 ou 5 tout au plus. Bref, c'est un bel outil mais qui ne me semble pas du tout pouvoir être vraiment utilisé en profondeur pour de la sécurité à grande échelle. Les nouvelles voies comme secomp sont peut être plus prometteuse du point de vu d'un utilisateur.
Bon à vrai dire, cela fait pas mal d'année que je ne lis plus LinuxMag et tout mon voisinage a suivis le même chemin. Il y en a qui savent si les éditions Diamond vont bien ? J'ai personnellement arrêté tout mes abonnements en voyant -1- que je ne les lisais plus et -2- que les éditions Diamond ne voulaient pas libérer TOUS les articles au bout d'un temps raisonnable, type 6 mois, dans le même esprit que LWN…
De toute manière, la MAIF avec son fonctionnement mutualiste, emmerde très certainement un certain nombre de gros de l'assurance qui aimerait bien éliminer les mutuelles sur lesquelles ils ont peu de prise !
La MAIF n'est pas une "boite" comme une autre. C'est un assureur mutualiste basé sur les enseignants de l'éducation nationale (au tout débuts des seuls instits). Dans le principe, c'est un peu comme une SCOOP. La MAIF appartient a ses adhérents avec un système d'élections… Il y a donc une longue tradition et dans le cas présent, ce ne serait pas facile de changer certaines choses ;-)
Il y a une ligne à changer pour avoir l'ancien comportement.
Perso, j'utilise mosh pour la connexion distante qui résiste au changement d'IP et de réseau ! Tu lances ton xpra dans une session mosh et tu as au final un truc beau ;-)
Bref, je ne me fais pas trop d'inquiétude, pleins de gens ont ce besoin sur ce genre de serveur (que je ne qualifie pas de HPC) et il y a donc une configuration qui marchera. Peu de gens actuellement font tourner VirtualGL sur leur poste perso (sans l'aide d'un sysadmin) donc adapter le système pour lui ne me semble pas inaccessible.
A partir du moment ou on a commencé à écrire les bureaux en variables globales, à ne pas vouloir relancer le bureau lors de reconfiguration mais où on voulait que tout se propage instantanément (dbus, gconfd…), on a commencé à faire des services au niveau session plutôt que d'utiliser des variables d'environnements pour transmettre des paramètres pères fils…
Cette évolution ayant été suivis pas presque tous les bureaux, il faut bien à la fin nettoyer la "merde" qui traîne un peu partout ;-)
des systemes HPC donc ce comportement est juste … debile
Je ne sais pas ce que tu fais comme HPC mais tous les systèmes que je connais, les scheduleurs dégomment tout lors de la fin du script de soumission (équivalent session) ou lorsqu'on arrive à l'échéance du temps du walltime. Si ton système HPC ne fonctionne pas ainsi, pour moi, ce n'est pas un système HPC car je ne vois pas comment le scheduleur pourrait dans ces conditions allouer correctement les ressources et faire des estimations de temps de passage.
Toutes les machines HPC de PRACE, GENCI ou des centres régionaux marchent sur ce principe.
Je reprends ta phrase sur la sécurité et je la place juste sur le concept de socket réseau ;-) Donc attention aux phrases trop générales… Quand aux DSI, on peut être pour ou contre mais cela ne changera rien. Leur comportement est un fait sociétal !
Ceci dis, cela ne me dérange pas que Debian lance ses services par défaut, au contraire. Une machine fraîchement installé n'est pas ouverte sur le net (DMZ) avant configuration… Un service, cela se configure via cfegnine, puppet… et si un service ne sers à rien, il n'est pas installé. Donc sur mes serveurs, un service installé est un service qui tourne. Je n'aime pas avoir du code dormant sur mes serveurs, je trouve cela plutôt dangereux !
Bref, un service mis sur off devrait être (sauf HA…) un service purgé du système de fichier ;-)
La sécurité ça consiste à bloquer les droits par défaut et à donner les droits le plus ponctuellement possible.
C'est un raisonnement tout à fait raisonnable mais il a eu un effet secondaire suite a son application généralisé par les DSI : la bascule de plein (presque tous) de service sur du https… Cette règle simple a malheureusement aussi des effets secondaires négatifs ;-)
Je le sais bien puisque je l'ai aussi proposé ailleurs ;-) L'idée ici est de garder une session en container qui est nettoyé en fin de session et d'envoyer simplement un processus hors de ce container de session, via at par exemple.
Pas tout vérifier mais sur un poste que je vois à distance, udev tourne, dbus aussi et je ne vois pas pourquoi ce qui marchait avant Jessie ne marcherait plus… Il me semblait que gnome ne dépendait de systemd que par un truc con facile a refaire.
En fait, je pense qu'on prends ici le problème à l'envers. Il faut voir que pour cloisonner les choses, on est entré dans le monde des containers (ou cgroup pour simplifié). Du coup, à l'ouverture de session, du ouvre un nouveau container et à la fermeture, tu le fermes. C'est aussi simple que cela et n'a rien à voir avec systemd ou logind ;-) Comme je l'ai dis, les sessions sur les clusters de calculs sont ainsi depuis des années. On pourrait très bien (on a déjà) avoir la même chose avec sysvinit !
Si tu veux lancer un processus qui survive au container, un screen ou un tmux, tu ne dois pas modifier screen ou tmux mais simplement les lancer hors du container. nohup lance hors du shell courant mais pas hors du container. Il faut juste changer cela ;-)
Mais que nohup s'appelle demain outainer ou un autre nom, personnellement, c'est bien pareil. Sur ce coup-ci, cela fait pas mal de temps (plusieurs années) qu'il est dis qu'un jour, la session utilisateur sera certainement par défaut dans un container et qu'il faudra changer quelques habitudes comme nohup… C'est pas un truc que les développeurs de screen ou tmux découvrent aujourd'hui ;-)
Sinon, il faut bien un paramètre admin à changer sur une machine car encore une fois, sur une machine de calcul, on ne peut pas laisser un utilisateur avoir des processus en nohup au delà de sa session (walltime). Bien que je n'aime pas la syntaxe CamelCase des projets gravitant autour de systemd, modifier une ligne, c'est pas la mort. Avec des outils comme cfengine, puppet ou équivalent, c'est déployer sur un parc de plus de 1000 machines en 1h…
Idée au pif (pas testé)
echo screen | at now +1s Puis dans un autre terminal, tu te connectes à cette session screen qui est normalement pérenne car envoyé par 'at' et non pas ta session !
En fait, le nouveau comportement en question ici, c'est pas tout à fait systemd mais logind. Sur une machine de calcul, lorsque tu lances un job via un scheduleur, il t'ouvre un cgroup ayant un cpuset, un memset… A la fin de ta session (walltime), le cgroup est supprimé avec tout ce qu'il y a avec. Job qui ne finit pas dans les temps ==> nettoyer !
En fait, logind fait exactement la même chose, désormais, il nettoie tout en fin de session via les mêmes mécanismes.
En fait, il faut JUSTE ré-écrire nohup pour qu'il ouvre une nouvelle session indépendante, dans un autre cgroup. Cela me parait tout à fait convenable et peut se faire via une IHM simple ;-) Il a été pris l'exemple de mosh plus haut et couplé à tmux, c'est hyper pratique (et simple)…
J'ai des machines sous Jessie qui sont restés sous sysvinit… Cela ne pose aucun soucis !
apt-get install sysvinit-core sysvinit-utils systemd-shim systemd-sysv-
A peu pres tout les HPC que je connais. Ok c'est pas generaliste mais c'est le marche le plus important de linux.
Heu non. Le marché le plus important de Linux est Androïd je pense puis on doit avoir derrière les Box ADSL… Le HPC est à mon avis très très loin derrière. En plus ChromeOS est soi-disant passé devant Apple sur les portables !
[^] # Re: Assembleur
Posté par Sytoka Modon (site web personnel) . En réponse au journal Code source de Apollo 11. Évalué à 2.
Difficile de ne pas avoir A = B + C plutôt que A = B - C… Ce genre de bogue n'est pas toujours évident à trouver. Ceci dis, la dernière norme Ada (2012) met en place les 'Type invariants' (http://www.ada2012.org/) qui permet d'éviter un certain d'erreur bête de ce genre.
Il me semble avoir entendu lors d'un exposé que la ligne 1 du métro a été automatisé en Esterel et qu'il n'a été trouvé aucun bogue. Cela semble trop beau pour être vrai à 100% mais je ne connais personne en interne pour confirmer / infirmer et je n'y connait rien en Esterel ;-)
[^] # Re: Assembleur
Posté par Sytoka Modon (site web personnel) . En réponse au journal Code source de Apollo 11. Évalué à 3.
Pour aller dans ton sens, la première version d'Ada est 83 suite aux premières étapes de sa création en 74 ! Ada est arrivé bien après de nombreux succès aéronautiques et spatiaux. D'ailleurs, les deux plus grosses catastrophes que sont les explosions des deux navettes ont lieu sous Ada mais celui-ci n'y était pour rien ;-)
# winbind
Posté par Sytoka Modon (site web personnel) . En réponse au message Montage home autofs nfs winbind (Résolu). Évalué à 2.
Normalement, winbind gère l'unicité des UID entre plusieurs serveurs sinon ton projet est mort et il ne faut pas faire de NFS… mais du pam_mount via SMB.
[^] # Re: asm
Posté par Sytoka Modon (site web personnel) . En réponse au journal Code source de Apollo 11. Évalué à 10.
Et puis on fait trop confiance au numérique de nos jours. La tour Eiffel n'a pas été calculé par ordinateur. La fusée Saturn V n'ont plus… On est capable de plein de bonne chose sans CPU.
D'un autre coté, le CPU nous donne la cotation boursière et les micro-transactions, la gouvernance sous l'emprise des INDEX de toute sorte… et la planète rougit !
Bref, les langages de haut niveau sont très bien mais ont aussi des travers ;-)
[^] # Re: Bonne idée mais...
Posté par Sytoka Modon (site web personnel) . En réponse au message Capabilités. Évalué à 2.
Je n'ai pas l'impression de me contredir. Certes CAP_NET_BIND_SERVICE permet d'avoir un serveur qui regarde sous les ports < 1024… Certes il y a plein de CAP intéressante. Mais en pratique et je l'avais lu quelques parts (LWN ?), les développeurs du noyau ne posent dans le code que quelques CAP_ du coup, le principe des CAP_ fait qu'il est peu utilisé…
La ligne de commande que j'ai donné n'est pas parfaite mais j'ai regardé avant sur pas mal de ligne et globalement, l'erreur final n'est pas si grande. Fait un "grep CAP_" dans les sources et tu verras par toi même… Les chiffres sont là et il y a malheureusement/effectivement quelques CAP fourre-tout qui ne doivent pas être loin du bit suid en pratique…
# Bonne idée mais...
Posté par Sytoka Modon (site web personnel) . En réponse au message Capabilités. Évalué à 2.
Je me suis amusé à faire la commande
ack '\bCAP_' | perl -p -e 's/.*\b(CAP_[A-Z_]+).*$/$1/;' | sort | uniq -c | sort -nsur les sources de mon noyau. Cela ne donne pas des stats précises au centième mais un bon indicateur.Je n'ai pas mis toutes les CAP qui sortent moins de 10 fois et qui sont en nombre très importantes… (Il y en a même pas mal qui ne sorte qu'une fois).
Bilan : la bonne idée s'est transformée en quelques CAP_SYSADMIN, 4 ou 5 tout au plus. Bref, c'est un bel outil mais qui ne me semble pas du tout pouvoir être vraiment utilisé en profondeur pour de la sécurité à grande échelle. Les nouvelles voies comme secomp sont peut être plus prometteuse du point de vu d'un utilisateur.
# Number one
Posté par Sytoka Modon (site web personnel) . En réponse au message [Donne] Magazines LinuxMag. Évalué à 2.
Argh, le numéro 1 !
Bon à vrai dire, cela fait pas mal d'année que je ne lis plus LinuxMag et tout mon voisinage a suivis le même chemin. Il y en a qui savent si les éditions Diamond vont bien ? J'ai personnellement arrêté tout mes abonnements en voyant -1- que je ne les lisais plus et -2- que les éditions Diamond ne voulaient pas libérer TOUS les articles au bout d'un temps raisonnable, type 6 mois, dans le même esprit que LWN…
[^] # Re: Nom de domaine dans quels TLD ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Cozy Cloud lève 4 millions d'euros (pour faire du libre). Évalué à 3. Dernière modification le 13 juin 2016 à 16:48.
De toute manière, la MAIF avec son fonctionnement mutualiste, emmerde très certainement un certain nombre de gros de l'assurance qui aimerait bien éliminer les mutuelles sur lesquelles ils ont peu de prise !
[^] # Re: MacOS, glorieuse époque?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Du neuf, enfin !. Évalué à 9.
-1- Ce n'est pas Apple qui a inventé le premier système pilotée à la souris mais Xerox
-2- Avant Macintosh, il y a eu Lisa qui a été le premier système pilotée à la souris chez Apple.
[^] # Re: Nom de domaine dans quels TLD ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Cozy Cloud lève 4 millions d'euros (pour faire du libre). Évalué à 7.
La MAIF n'est pas une "boite" comme une autre. C'est un assureur mutualiste basé sur les enseignants de l'éducation nationale (au tout débuts des seuls instits). Dans le principe, c'est un peu comme une SCOOP. La MAIF appartient a ses adhérents avec un système d'élections… Il y a donc une longue tradition et dans le cas présent, ce ne serait pas facile de changer certaines choses ;-)
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 5. Dernière modification le 06 juin 2016 à 21:49.
Il y a une ligne à changer pour avoir l'ancien comportement.
Perso, j'utilise mosh pour la connexion distante qui résiste au changement d'IP et de réseau ! Tu lances ton xpra dans une session mosh et tu as au final un truc beau ;-)
Bref, je ne me fais pas trop d'inquiétude, pleins de gens ont ce besoin sur ce genre de serveur (que je ne qualifie pas de HPC) et il y a donc une configuration qui marchera. Peu de gens actuellement font tourner VirtualGL sur leur poste perso (sans l'aide d'un sysadmin) donc adapter le système pour lui ne me semble pas inaccessible.
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 2.
A partir du moment ou on a commencé à écrire les bureaux en variables globales, à ne pas vouloir relancer le bureau lors de reconfiguration mais où on voulait que tout se propage instantanément (dbus, gconfd…), on a commencé à faire des services au niveau session plutôt que d'utiliser des variables d'environnements pour transmettre des paramètres pères fils…
Cette évolution ayant été suivis pas presque tous les bureaux, il faut bien à la fin nettoyer la "merde" qui traîne un peu partout ;-)
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 7.
Je ne sais pas ce que tu fais comme HPC mais tous les systèmes que je connais, les scheduleurs dégomment tout lors de la fin du script de soumission (équivalent session) ou lorsqu'on arrive à l'échéance du temps du walltime. Si ton système HPC ne fonctionne pas ainsi, pour moi, ce n'est pas un système HPC car je ne vois pas comment le scheduleur pourrait dans ces conditions allouer correctement les ressources et faire des estimations de temps de passage.
Toutes les machines HPC de PRACE, GENCI ou des centres régionaux marchent sur ce principe.
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 1.
Je reprends ta phrase sur la sécurité et je la place juste sur le concept de socket réseau ;-) Donc attention aux phrases trop générales… Quand aux DSI, on peut être pour ou contre mais cela ne changera rien. Leur comportement est un fait sociétal !
Ceci dis, cela ne me dérange pas que Debian lance ses services par défaut, au contraire. Une machine fraîchement installé n'est pas ouverte sur le net (DMZ) avant configuration… Un service, cela se configure via cfegnine, puppet… et si un service ne sers à rien, il n'est pas installé. Donc sur mes serveurs, un service installé est un service qui tourne. Je n'aime pas avoir du code dormant sur mes serveurs, je trouve cela plutôt dangereux !
Bref, un service mis sur off devrait être (sauf HA…) un service purgé du système de fichier ;-)
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 4.
C'est un raisonnement tout à fait raisonnable mais il a eu un effet secondaire suite a son application généralisé par les DSI : la bascule de plein (presque tous) de service sur du https… Cette règle simple a malheureusement aussi des effets secondaires négatifs ;-)
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 4.
Je le sais bien puisque je l'ai aussi proposé ailleurs ;-) L'idée ici est de garder une session en container qui est nettoyé en fin de session et d'envoyer simplement un processus hors de ce container de session, via at par exemple.
[^] # Re: Bug fermé chez tmux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 1.
Pas tout vérifier mais sur un poste que je vois à distance, udev tourne, dbus aussi et je ne vois pas pourquoi ce qui marchait avant Jessie ne marcherait plus… Il me semblait que gnome ne dépendait de systemd que par un truc con facile a refaire.
[^] # Re: systemd, le nouveau Multics
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 10.
En fait, je pense qu'on prends ici le problème à l'envers. Il faut voir que pour cloisonner les choses, on est entré dans le monde des containers (ou cgroup pour simplifié). Du coup, à l'ouverture de session, du ouvre un nouveau container et à la fermeture, tu le fermes. C'est aussi simple que cela et n'a rien à voir avec systemd ou logind ;-) Comme je l'ai dis, les sessions sur les clusters de calculs sont ainsi depuis des années. On pourrait très bien (on a déjà) avoir la même chose avec sysvinit !
Si tu veux lancer un processus qui survive au container, un screen ou un tmux, tu ne dois pas modifier screen ou tmux mais simplement les lancer hors du container. nohup lance hors du shell courant mais pas hors du container. Il faut juste changer cela ;-)
Mais que nohup s'appelle demain outainer ou un autre nom, personnellement, c'est bien pareil. Sur ce coup-ci, cela fait pas mal de temps (plusieurs années) qu'il est dis qu'un jour, la session utilisateur sera certainement par défaut dans un container et qu'il faudra changer quelques habitudes comme nohup… C'est pas un truc que les développeurs de screen ou tmux découvrent aujourd'hui ;-)
Sinon, il faut bien un paramètre admin à changer sur une machine car encore une fois, sur une machine de calcul, on ne peut pas laisser un utilisateur avoir des processus en nohup au delà de sa session (walltime). Bien que je n'aime pas la syntaxe CamelCase des projets gravitant autour de systemd, modifier une ligne, c'est pas la mort. Avec des outils comme cfengine, puppet ou équivalent, c'est déployer sur un parc de plus de 1000 machines en 1h…
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 2.
Idée au pif (pas testé)
echo screen | at now +1s
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 2.
Yep, mosh charge un peu trop (tmux surtout il me semble).
Redirection -> pouvoir glisser via mosh un retour graphique xpra par exemple ;-)
[^] # Re: systemd, le nouveau Multics
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 8.
En fait, le nouveau comportement en question ici, c'est pas tout à fait systemd mais logind. Sur une machine de calcul, lorsque tu lances un job via un scheduleur, il t'ouvre un cgroup ayant un cpuset, un memset… A la fin de ta session (walltime), le cgroup est supprimé avec tout ce qu'il y a avec. Job qui ne finit pas dans les temps ==> nettoyer !
En fait, logind fait exactement la même chose, désormais, il nettoie tout en fin de session via les mêmes mécanismes.
En fait, il faut JUSTE ré-écrire nohup pour qu'il ouvre une nouvelle session indépendante, dans un autre cgroup. Cela me parait tout à fait convenable et peut se faire via une IHM simple ;-) Il a été pris l'exemple de mosh plus haut et couplé à tmux, c'est hyper pratique (et simple)…
[^] # Re: Depuis NEWS
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 2.
Elle est documentée partout. Arrêtons la mauvaise foi et essayons d'être optimiste ;-)
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 2.
Yep, mosh + tmux (byobu) marche d'enfer et la charge réseau est TRES TRES faible (on attend juste la redirection de port).
[^] # Re: Bug fermé chez tmux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 1.
J'ai des machines sous Jessie qui sont restés sous sysvinit… Cela ne pose aucun soucis !
apt-get install sysvinit-core sysvinit-utils systemd-shim systemd-sysv-
[^] # Re: Intérêt de ne pas faire la mise à jour ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Vague d’intérêt pour GNU/Linux vs Windows 10 « imposé » ?. Évalué à 4.
Heu non. Le marché le plus important de Linux est Androïd je pense puis on doit avoir derrière les Box ADSL… Le HPC est à mon avis très très loin derrière. En plus ChromeOS est soi-disant passé devant Apple sur les portables !