Comment ajouter des application sur slackware and family
66 réponses
jp willm
Le 12/11/2014 07:16, Doug713705 a écrit :
>> Ce sera aussi facile, plus édifiant et plus gratifiant de tester une
>> *buntu
>
> Là par contre, je suis d'accord
>
Tiens, j'en profite :
J'ai booté sur vectro-linux et Salix en live
Rien à redire tout fonctionnait et au niveau "déco/ergonomie", les deux
sont bien fichues.
Mais sur la vector, j'ai essayé de voir comment je pourrais installer
dolphin en plus de thunar le jour où je l'installe pour de vrai.
Alors j'ai essayé les différents "dépôt" slackware, mais n'ai rien trouvé.
J'ai essayé de voir si je peux trouver un tar.gz, mais en vain.
J'ai bien trouvé un script, mais n'ai plus eu le temps de lire le détail
pour aller plus loin.
Je ne demande pas forcément qu'on me prémâche le travail, mais une
petite indication sur la façon d'installer des applications ou une
adresse pour trouver les sources aurait été bienvenue.
Néanmoins je suis d'accord pour dire que le système d'init est à revoir mais on pourrait envisager une alternative sérieuse pas un bloat qui va du serveur DNS au serveur HTTP en passant par une gestion des logs.
Le serveur DNS et le serveur HTTP, c'est du FUD propagé par les détracteurs, je t'invite à te documenter par toi-même avant de te forger des opinions à l'emporte-pièce.
La gestion des logs, ça me semble parfaitement à sa place : comment savoir pourquoi un daemon ne démarre pas sans ses logs.
Cet amoncellement ne veut *rien* dire et avance au petit bonheur la chance sans réèllle vision globale.
C'est complètement le contraire, c'est le système actuelle qui n'a aucune vision globale.
Doug713705 , dans le message <ne7gjbxpoa.ln2@actarus.redatomik.org>, a
écrit :
Néanmoins je suis d'accord pour dire que le système d'init est à revoir
mais on pourrait envisager une alternative sérieuse pas un bloat qui va
du serveur DNS au serveur HTTP en passant par une gestion des logs.
Le serveur DNS et le serveur HTTP, c'est du FUD propagé par les détracteurs,
je t'invite à te documenter par toi-même avant de te forger des opinions à
l'emporte-pièce.
La gestion des logs, ça me semble parfaitement à sa place : comment savoir
pourquoi un daemon ne démarre pas sans ses logs.
Cet amoncellement ne veut *rien* dire et avance au petit bonheur la
chance sans réèllle vision globale.
C'est complètement le contraire, c'est le système actuelle qui n'a aucune
vision globale.
Néanmoins je suis d'accord pour dire que le système d'init est à revoir mais on pourrait envisager une alternative sérieuse pas un bloat qui va du serveur DNS au serveur HTTP en passant par une gestion des logs.
Le serveur DNS et le serveur HTTP, c'est du FUD propagé par les détracteurs, je t'invite à te documenter par toi-même avant de te forger des opinions à l'emporte-pièce.
La gestion des logs, ça me semble parfaitement à sa place : comment savoir pourquoi un daemon ne démarre pas sans ses logs.
Cet amoncellement ne veut *rien* dire et avance au petit bonheur la chance sans réèllle vision globale.
C'est complètement le contraire, c'est le système actuelle qui n'a aucune vision globale.
Nicolas George
Erwan David , dans le message , a écrit :
Et surtout un truc totalement instable en changement permanent et qui se traine des trouys de sécurité vieux de 20 ans...
Euh, systemd a largement moins de vingt ans, donc ça m'a l'air d'être encore purement du FUD.
Erwan David , dans le message <87wq6ys2nf.fsf@tee.rail.eu.org>, a
écrit :
Et surtout un truc totalement instable en changement permanent et qui se
traine des trouys de sécurité vieux de 20 ans...
Euh, systemd a largement moins de vingt ans, donc ça m'a l'air d'être encore
purement du FUD.
Et surtout un truc totalement instable en changement permanent et qui se traine des trouys de sécurité vieux de 20 ans...
Euh, systemd a largement moins de vingt ans, donc ça m'a l'air d'être encore purement du FUD.
Doug713705
Le 14-11-2014, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<5465b535$0$1987$) :
Doug713705 , dans le message , a écrit :
Néanmoins je suis d'accord pour dire que le système d'init est à revoir mais on pourrait envisager une alternative sérieuse pas un bloat qui va du serveur DNS au serveur HTTP en passant par une gestion des logs.
Le serveur DNS et le serveur HTTP, c'est du FUD propagé par les détracteurs, je t'invite à te documenter par toi-même avant de te forger des opinions à l'emporte-pièce.
"systemd-resolved contains a caching resolver, which has to be enabled via /etc/nsswitch.conf in order to be integrated. Any local name resolvings via getaddrinfo() etc. are then routed via DBUS to systemd-resolved *which resolves the name and caches it* according to TTL from the answer.""
Mais j'y lis encore: "At its simplest, an attacker triggers a query to a domain he controls via SMTP or SSH-login. Upon receipt of the question, he can just add any answer he wants to have cached to the legit answer he provides for the query, e.g. providing two anser RR's: One for the question asked and one for a question that has never been asked - even if the DNS server is not authoritative for this domain."
ROFL
La gestion des logs, ça me semble parfaitement à sa place : comment savoir pourquoi un daemon ne démarre pas sans ses logs.
Ah ben oui, c'est à peu prêt la seule chose de pertinente dans systemd.
Cet amoncellement ne veut *rien* dire et avance au petit bonheur la chance sans réèllle vision globale.
C'est complètement le contraire, c'est le système actuelle qui n'a aucune vision globale.
Ce n'est pas parce que le système actuel est vieux que systemd est mieux.
L'ancien systeme à l'énorme avantage de _fonctionner_ depuis des *décénnies* quand systemd ne fonctionen toujours pas autrement que sur le papier.
Je ne comprends pas que systemd, un bloatware qui vise à remplacer init, le processus le plus critique du sysème, ait pu être adopté alors qu'il est clairement pas sec (il est d'ailleurs à peine peint).
Ce truc c'est le mur assuré mais l'échéance sera longue et le réveil brutal.
C'est BSD et Apple qui vous remercieront.
-- Fais moi une place dans ton linceul Quand y'en a pour un y'en a pour deux Fais moi une place dans ton linceul Pour un coup de dents je t'arrache les yeux. -- H.F. Thiéfaine, Scène de panique tranquille
Le 14-11-2014, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<5465b535$0$1987$426a74cc@news.free.fr>) :
Doug713705 , dans le message <ne7gjbxpoa.ln2@actarus.redatomik.org>, a
écrit :
Néanmoins je suis d'accord pour dire que le système d'init est à revoir
mais on pourrait envisager une alternative sérieuse pas un bloat qui va
du serveur DNS au serveur HTTP en passant par une gestion des logs.
Le serveur DNS et le serveur HTTP, c'est du FUD propagé par les détracteurs,
je t'invite à te documenter par toi-même avant de te forger des opinions à
l'emporte-pièce.
"systemd-resolved contains a caching resolver, which has to be enabled
via /etc/nsswitch.conf in order to be integrated.
Any local name resolvings via getaddrinfo() etc. are then routed via
DBUS to systemd-resolved *which resolves the name and caches it*
according to TTL from the answer.""
Mais j'y lis encore:
"At its simplest, an attacker triggers a query to a domain he controls
via SMTP or SSH-login. Upon receipt of the question, he can just add
any answer he wants to have cached to the legit answer he provides
for the query, e.g. providing two anser RR's: One for the question asked
and one for a question that has never been asked - even if the DNS
server is not authoritative for this domain."
ROFL
La gestion des logs, ça me semble parfaitement à sa place : comment savoir
pourquoi un daemon ne démarre pas sans ses logs.
Ah ben oui, c'est à peu prêt la seule chose de pertinente dans systemd.
Cet amoncellement ne veut *rien* dire et avance au petit bonheur la
chance sans réèllle vision globale.
C'est complètement le contraire, c'est le système actuelle qui n'a aucune
vision globale.
Ce n'est pas parce que le système actuel est vieux que systemd est
mieux.
L'ancien systeme à l'énorme avantage de _fonctionner_ depuis des
*décénnies* quand systemd ne fonctionen toujours pas autrement que sur
le papier.
Je ne comprends pas que systemd, un bloatware qui vise à remplacer init,
le processus le plus critique du sysème, ait pu être adopté alors qu'il
est clairement pas sec (il est d'ailleurs à peine peint).
Ce truc c'est le mur assuré mais l'échéance sera longue et le réveil
brutal.
C'est BSD et Apple qui vous remercieront.
--
Fais moi une place dans ton linceul
Quand y'en a pour un y'en a pour deux
Fais moi une place dans ton linceul
Pour un coup de dents je t'arrache les yeux.
-- H.F. Thiéfaine, Scène de panique tranquille
Le 14-11-2014, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<5465b535$0$1987$) :
Doug713705 , dans le message , a écrit :
Néanmoins je suis d'accord pour dire que le système d'init est à revoir mais on pourrait envisager une alternative sérieuse pas un bloat qui va du serveur DNS au serveur HTTP en passant par une gestion des logs.
Le serveur DNS et le serveur HTTP, c'est du FUD propagé par les détracteurs, je t'invite à te documenter par toi-même avant de te forger des opinions à l'emporte-pièce.
"systemd-resolved contains a caching resolver, which has to be enabled via /etc/nsswitch.conf in order to be integrated. Any local name resolvings via getaddrinfo() etc. are then routed via DBUS to systemd-resolved *which resolves the name and caches it* according to TTL from the answer.""
Mais j'y lis encore: "At its simplest, an attacker triggers a query to a domain he controls via SMTP or SSH-login. Upon receipt of the question, he can just add any answer he wants to have cached to the legit answer he provides for the query, e.g. providing two anser RR's: One for the question asked and one for a question that has never been asked - even if the DNS server is not authoritative for this domain."
ROFL
La gestion des logs, ça me semble parfaitement à sa place : comment savoir pourquoi un daemon ne démarre pas sans ses logs.
Ah ben oui, c'est à peu prêt la seule chose de pertinente dans systemd.
Cet amoncellement ne veut *rien* dire et avance au petit bonheur la chance sans réèllle vision globale.
C'est complètement le contraire, c'est le système actuelle qui n'a aucune vision globale.
Ce n'est pas parce que le système actuel est vieux que systemd est mieux.
L'ancien systeme à l'énorme avantage de _fonctionner_ depuis des *décénnies* quand systemd ne fonctionen toujours pas autrement que sur le papier.
Je ne comprends pas que systemd, un bloatware qui vise à remplacer init, le processus le plus critique du sysème, ait pu être adopté alors qu'il est clairement pas sec (il est d'ailleurs à peine peint).
Ce truc c'est le mur assuré mais l'échéance sera longue et le réveil brutal.
C'est BSD et Apple qui vous remercieront.
-- Fais moi une place dans ton linceul Quand y'en a pour un y'en a pour deux Fais moi une place dans ton linceul Pour un coup de dents je t'arrache les yeux. -- H.F. Thiéfaine, Scène de panique tranquille
Erwan David
Nicolas George <nicolas$ écrivait :
Erwan David , dans le message , a écrit :
Et surtout un truc totalement instable en changement permanent et qui se traine des trouys de sécurité vieux de 20 ans...
Euh, systemd a largement moins de vingt ans, donc ça m'a l'air d'être encore purement du FUD.
AH, le cache poisoining DNS c'est largement plus vieux que systemd, c'est juste que c'est revebnu dedans...
C'est pas sec, mal fait, avec un design foireux.
-- Les simplifications c'est trop compliqué
Nicolas George <nicolas$george@salle-s.org> écrivait :
Erwan David , dans le message <87wq6ys2nf.fsf@tee.rail.eu.org>, a
écrit :
Et surtout un truc totalement instable en changement permanent et qui se
traine des trouys de sécurité vieux de 20 ans...
Euh, systemd a largement moins de vingt ans, donc ça m'a l'air d'être encore
purement du FUD.
AH, le cache poisoining DNS c'est largement plus vieux que systemd,
c'est juste que c'est revebnu dedans...
AH, le cache poisoining DNS c'est largement plus vieux que systemd, c'est juste que c'est revebnu dedans...
[citation needed]
Accessoirement, merci de ne pas confondre les principes et l'implémentation.
Eric Masson
Erwan David writes:
'Lut,
C'est pas sec, mal fait, avec un design foireux.
Et ça ne risque pas de changer vu que le dev principal est convaincu de détenir la vérité et n'en a rien à carrer des avis souvent éclairés des trouducs qui gravitent dans l'écosystème Linux.
L'attitude de ce mec me fait penser à celle de l'ex mainteneur de la glibc, il y a vraiment de sérieux problèmes d'égo dans ce milieu...
--
Le neuneu est un con qui débute. C'est une espèce rare mais qui fait beaucoup de bruit.
-+- JCD in Guide du Linuxien pervers - Bien configurer son neuneu.
Erwan David <erwan@rail.eu.org> writes:
'Lut,
C'est pas sec, mal fait, avec un design foireux.
Et ça ne risque pas de changer vu que le dev principal est convaincu de
détenir la vérité et n'en a rien à carrer des avis souvent éclairés des
trouducs qui gravitent dans l'écosystème Linux.
L'attitude de ce mec me fait penser à celle de l'ex mainteneur de la
glibc, il y a vraiment de sérieux problèmes d'égo dans ce milieu...
--
Le neuneu est un con qui débute. C'est une espèce rare mais qui fait
beaucoup de bruit.
-+- JCD in Guide du Linuxien pervers - Bien configurer son neuneu.
Et ça ne risque pas de changer vu que le dev principal est convaincu de détenir la vérité et n'en a rien à carrer des avis souvent éclairés des trouducs qui gravitent dans l'écosystème Linux.
L'attitude de ce mec me fait penser à celle de l'ex mainteneur de la glibc, il y a vraiment de sérieux problèmes d'égo dans ce milieu...
--
Le neuneu est un con qui débute. C'est une espèce rare mais qui fait beaucoup de bruit.
-+- JCD in Guide du Linuxien pervers - Bien configurer son neuneu.
Nicolas George
Doug713705 , dans le message , a écrit :
"systemd-resolved
Et donc dès le premier mot, tu aurais pu te rendre compte qu'il ne s'agit pas de systemd mais d'un module périphérique optionnel.
Ah ben oui, c'est à peu prêt la seule chose de pertinente dans systemd.
Tu disais le contraire il y a un message. Dans dix messages tu seras convaincu que systemd est l'avenir.
Ce n'est pas parce que le système actuel est vieux que systemd est mieux.
Non, c'est parce que le système actuel est pourri que systemd est mieux.
L'ancien systeme à l'énorme avantage de _fonctionner_ depuis des *décénnies*
NON, c'est faux. Le système actuel ne fonctionne pas. Au mieux il marchotte, mais pas plus.
Je ne comprends pas que systemd, un bloatware qui vise à remplacer init, le processus le plus critique du sysème,
Tu reprends encore de la propagande sans esprit critique. init n'a rien de critique.
Doug713705 , dans le message <8rtgjbx3mh.ln2@actarus.redatomik.org>, a
écrit :
"systemd-resolved
Et donc dès le premier mot, tu aurais pu te rendre compte qu'il ne s'agit
pas de systemd mais d'un module périphérique optionnel.
Ah ben oui, c'est à peu prêt la seule chose de pertinente dans systemd.
Tu disais le contraire il y a un message. Dans dix messages tu seras
convaincu que systemd est l'avenir.
Ce n'est pas parce que le système actuel est vieux que systemd est
mieux.
Non, c'est parce que le système actuel est pourri que systemd est mieux.
L'ancien systeme à l'énorme avantage de _fonctionner_ depuis des
*décénnies*
NON, c'est faux. Le système actuel ne fonctionne pas. Au mieux il marchotte,
mais pas plus.
Je ne comprends pas que systemd, un bloatware qui vise à remplacer init,
le processus le plus critique du sysème,
Tu reprends encore de la propagande sans esprit critique. init n'a rien de
critique.
Et donc dès le premier mot, tu aurais pu te rendre compte qu'il ne s'agit pas de systemd mais d'un module périphérique optionnel.
Ah ben oui, c'est à peu prêt la seule chose de pertinente dans systemd.
Tu disais le contraire il y a un message. Dans dix messages tu seras convaincu que systemd est l'avenir.
Ce n'est pas parce que le système actuel est vieux que systemd est mieux.
Non, c'est parce que le système actuel est pourri que systemd est mieux.
L'ancien systeme à l'énorme avantage de _fonctionner_ depuis des *décénnies*
NON, c'est faux. Le système actuel ne fonctionne pas. Au mieux il marchotte, mais pas plus.
Je ne comprends pas que systemd, un bloatware qui vise à remplacer init, le processus le plus critique du sysème,
Tu reprends encore de la propagande sans esprit critique. init n'a rien de critique.
Nicolas George
Doug713705 , dans le message , a écrit :
Si mais "bizzarement" il y en a moins.
Ah mais oui, suis-je bête, ma Slackware stable n'utilise pas de libs avec 42 versions de retard et ne patche rien. Ceci doit expliquer cela.
Si l'upstream se fiche de la sécurité, tu ferais mieux de passer sous silence le fait de ne rien patcher.
Il n'y a pas de miracles, si Debian a beaucoup de correctifs de sécurité, c'est qu'il y a beaucoup de bugs dans leurs logiciels, et comme, malgré ce que disent les mauvaises langues, les patches de Debian vont plus souvent enlever des bugs qu'en rajouter, ces bugs sont aussi dans Slackware.
Donc si tu as moins de mises à jour sur Slackware, c'est juste qu'il te reste plus de trous.
Doug713705 , dans le message <dt6gjbxpoa.ln2@actarus.redatomik.org>, a
écrit :
Si mais "bizzarement" il y en a moins.
Ah mais oui, suis-je bête, ma Slackware stable n'utilise pas de libs
avec 42 versions de retard et ne patche rien. Ceci doit expliquer cela.
Si l'upstream se fiche de la sécurité, tu ferais mieux de passer sous
silence le fait de ne rien patcher.
Il n'y a pas de miracles, si Debian a beaucoup de correctifs de sécurité,
c'est qu'il y a beaucoup de bugs dans leurs logiciels, et comme, malgré ce
que disent les mauvaises langues, les patches de Debian vont plus souvent
enlever des bugs qu'en rajouter, ces bugs sont aussi dans Slackware.
Donc si tu as moins de mises à jour sur Slackware, c'est juste qu'il te
reste plus de trous.
Ah mais oui, suis-je bête, ma Slackware stable n'utilise pas de libs avec 42 versions de retard et ne patche rien. Ceci doit expliquer cela.
Si l'upstream se fiche de la sécurité, tu ferais mieux de passer sous silence le fait de ne rien patcher.
Il n'y a pas de miracles, si Debian a beaucoup de correctifs de sécurité, c'est qu'il y a beaucoup de bugs dans leurs logiciels, et comme, malgré ce que disent les mauvaises langues, les patches de Debian vont plus souvent enlever des bugs qu'en rajouter, ces bugs sont aussi dans Slackware.
Donc si tu as moins de mises à jour sur Slackware, c'est juste qu'il te reste plus de trous.
Nicolas George
FGK , dans le message , a écrit :
Non, ça n'est pas ça. Simplement les "slackeux" (par les dieux que je n'aime pas ce terme)
Ce n'est pas moi qui l'ai employé en premier ici.
ont un cerveau multitâche et sont capables de lancer une compilation puis de passer à une autre activité.
Si tu veux faire une analogie, au moins fais la bien : quand un processeur doit passer d'un contexte à un autre, ça a un coût, principalement sous la forme des caches du processeur qui ont besoin d'être reremplis. C'est pareil pour un humain : s'il s'interrompt d'une tâche pour en faire une autre, il a besoin d'un temps pour retrouver son contexte en revenant à la première, et ce temps est d'autant plus long que l'interruption elle-même a été plus longue et mentalement prenante.
Après, ça dépend ce que tu fais, évidemment. Si l'usage le plus compliqué que tu fais de ton ordinateur c'est de faire une partie de solitaire pendant que le démineur compile, alors oui, tu peux commuter facilement.
FGK , dans le message <slrnm6arp4.tc4.f6k@shyla.porneia.net>, a écrit :
Non, ça n'est pas ça. Simplement les "slackeux" (par les dieux que je n'aime
pas ce terme)
Ce n'est pas moi qui l'ai employé en premier ici.
ont un cerveau multitâche et sont capables de lancer une
compilation puis de passer à une autre activité.
Si tu veux faire une analogie, au moins fais la bien : quand un processeur
doit passer d'un contexte à un autre, ça a un coût, principalement sous la
forme des caches du processeur qui ont besoin d'être reremplis. C'est pareil
pour un humain : s'il s'interrompt d'une tâche pour en faire une autre, il a
besoin d'un temps pour retrouver son contexte en revenant à la première, et
ce temps est d'autant plus long que l'interruption elle-même a été plus
longue et mentalement prenante.
Après, ça dépend ce que tu fais, évidemment. Si l'usage le plus compliqué
que tu fais de ton ordinateur c'est de faire une partie de solitaire pendant
que le démineur compile, alors oui, tu peux commuter facilement.
Non, ça n'est pas ça. Simplement les "slackeux" (par les dieux que je n'aime pas ce terme)
Ce n'est pas moi qui l'ai employé en premier ici.
ont un cerveau multitâche et sont capables de lancer une compilation puis de passer à une autre activité.
Si tu veux faire une analogie, au moins fais la bien : quand un processeur doit passer d'un contexte à un autre, ça a un coût, principalement sous la forme des caches du processeur qui ont besoin d'être reremplis. C'est pareil pour un humain : s'il s'interrompt d'une tâche pour en faire une autre, il a besoin d'un temps pour retrouver son contexte en revenant à la première, et ce temps est d'autant plus long que l'interruption elle-même a été plus longue et mentalement prenante.
Après, ça dépend ce que tu fais, évidemment. Si l'usage le plus compliqué que tu fais de ton ordinateur c'est de faire une partie de solitaire pendant que le démineur compile, alors oui, tu peux commuter facilement.
Benoit Izac
Bonjour,
le 13/11/2014 à 23:31, Nicolas George a écrit dans le message <54653155$0$2896$ :
Bonne lecture !
Tu aurais mieux fait de le lire toi-même, tu aurais peut-être remarqué les premiers motds : « can be used ». Au cas où tu aurais du mal en anglais, « can », c'est pouvoir, pas devoir. Rien ne t'oblige à l'utiliser.
Non rien ne m'y oblige mais c'est activé par défaut (et tu le sais puisque tu l'as lu trois lignes plus bas). En effaçant soigneusement le sujet de la discussion, tu changes la conversation en ta faveur. Pour rappel la question était : « Quel rapport entre systemd et les core dumps ? ». Tu as eu ta réponse.
Maintenant pour répondre à ta remarque concernant /var/syslog/xxx et les core dump, effectivement, je peux dire à systemd d'envoyer les log vers syslog et je peux désactiver systemd-coredump mais ce que j'explique dans mon message initial, c'est que je me suis retouvé un beau jour avec plus de core dump dans le répertoire courant et /var/log/xxx contenant des fichiers vides et ça m'a cassé les pieds de lire des man pages et faire des recherches web pour trouver l'explication. J'étais bien habitué à mon petit environnement et systemd est venu tout compliqué. Si tu ne peux pas comprendre ça, je ne peux rien faire pour toi.
-- Benoit Izac
Bonjour,
le 13/11/2014 à 23:31, Nicolas George a écrit dans le message
<54653155$0$2896$426a74cc@news.free.fr> :
Bonne lecture !
Tu aurais mieux fait de le lire toi-même, tu aurais peut-être remarqué les
premiers motds : « can be used ». Au cas où tu aurais du mal en anglais,
« can », c'est pouvoir, pas devoir. Rien ne t'oblige à l'utiliser.
Non rien ne m'y oblige mais c'est activé par défaut (et tu le sais
puisque tu l'as lu trois lignes plus bas). En effaçant soigneusement le
sujet de la discussion, tu changes la conversation en ta faveur. Pour
rappel la question était : « Quel rapport entre systemd et les core
dumps ? ». Tu as eu ta réponse.
Maintenant pour répondre à ta remarque concernant /var/syslog/xxx et les
core dump, effectivement, je peux dire à systemd d'envoyer les log vers
syslog et je peux désactiver systemd-coredump mais ce que j'explique
dans mon message initial, c'est que je me suis retouvé un beau jour avec
plus de core dump dans le répertoire courant et /var/log/xxx contenant
des fichiers vides et ça m'a cassé les pieds de lire des man pages et
faire des recherches web pour trouver l'explication. J'étais bien
habitué à mon petit environnement et systemd est venu tout compliqué. Si
tu ne peux pas comprendre ça, je ne peux rien faire pour toi.
le 13/11/2014 à 23:31, Nicolas George a écrit dans le message <54653155$0$2896$ :
Bonne lecture !
Tu aurais mieux fait de le lire toi-même, tu aurais peut-être remarqué les premiers motds : « can be used ». Au cas où tu aurais du mal en anglais, « can », c'est pouvoir, pas devoir. Rien ne t'oblige à l'utiliser.
Non rien ne m'y oblige mais c'est activé par défaut (et tu le sais puisque tu l'as lu trois lignes plus bas). En effaçant soigneusement le sujet de la discussion, tu changes la conversation en ta faveur. Pour rappel la question était : « Quel rapport entre systemd et les core dumps ? ». Tu as eu ta réponse.
Maintenant pour répondre à ta remarque concernant /var/syslog/xxx et les core dump, effectivement, je peux dire à systemd d'envoyer les log vers syslog et je peux désactiver systemd-coredump mais ce que j'explique dans mon message initial, c'est que je me suis retouvé un beau jour avec plus de core dump dans le répertoire courant et /var/log/xxx contenant des fichiers vides et ça m'a cassé les pieds de lire des man pages et faire des recherches web pour trouver l'explication. J'étais bien habitué à mon petit environnement et systemd est venu tout compliqué. Si tu ne peux pas comprendre ça, je ne peux rien faire pour toi.
