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.
D'un autre coté un trou qui permettrait à un utilisateur local qui aurait pris le temps nécessaire de lire la doc relative à un exploit, de coder de quoi réaliser cet exploit afin de faire un DoS ou une escalade de priviliège sur *ma* machine dont je suis le seul utilisateur. Comment dire ?
Dans la sécurité il y a aussi le caclul du risque. Ici le risque est de niveau zéro, je n'ai donc aucune raison de metre à jour.
Note que je ne dis pas qu'il faille esquiver toutes les mise à jour.
Donc tu serais d'accord pour dire que Slackware convient au bricolo qui fait joujou dans sa cave mais pas pour un usage sérieux ?
Par ailleurs corriger des libs antédiluvienne dont les versions actuelle ont déjà corrigé le problème...
... ce n'est pas bien difficile en général.
Doug713705 , dans le message <ln4ijbx96s.ln2@actarus.redatomik.org>, a
écrit :
D'un autre coté un trou qui permettrait à un utilisateur local qui
aurait pris le temps nécessaire de lire la doc relative à un exploit,
de coder de quoi réaliser cet exploit afin de faire un DoS ou une
escalade de priviliège sur *ma* machine dont je suis le seul
utilisateur. Comment dire ?
Dans la sécurité il y a aussi le caclul du risque. Ici le risque est
de niveau zéro, je n'ai donc aucune raison de metre à jour.
Note que je ne dis pas qu'il faille esquiver toutes les mise à jour.
Donc tu serais d'accord pour dire que Slackware convient au bricolo qui fait
joujou dans sa cave mais pas pour un usage sérieux ?
Par ailleurs corriger des libs antédiluvienne dont les versions actuelle
ont déjà corrigé le problème...
D'un autre coté un trou qui permettrait à un utilisateur local qui aurait pris le temps nécessaire de lire la doc relative à un exploit, de coder de quoi réaliser cet exploit afin de faire un DoS ou une escalade de priviliège sur *ma* machine dont je suis le seul utilisateur. Comment dire ?
Dans la sécurité il y a aussi le caclul du risque. Ici le risque est de niveau zéro, je n'ai donc aucune raison de metre à jour.
Note que je ne dis pas qu'il faille esquiver toutes les mise à jour.
Donc tu serais d'accord pour dire que Slackware convient au bricolo qui fait joujou dans sa cave mais pas pour un usage sérieux ?
Par ailleurs corriger des libs antédiluvienne dont les versions actuelle ont déjà corrigé le problème...
... ce n'est pas bien difficile en général.
Nicolas George
FGK , dans le message , a écrit :
Le contexte ici est la compilation d'une application
Non, le contexte c'est ce qu'on était en train de faire quand on s'est rendu compte qu'on avait besoin d'une application ou d'une bibliothèque qui n'est pas installée. Plus l'installation prend du temps, plus il y a de risques de perdre le fil de pensée entre temps.
FGK , dans le message <slrnm6djbo.aa0.f6k@shyla.porneia.net>, a écrit :
Le contexte ici est la compilation d'une application
Non, le contexte c'est ce qu'on était en train de faire quand on s'est rendu
compte qu'on avait besoin d'une application ou d'une bibliothèque qui n'est
pas installée. Plus l'installation prend du temps, plus il y a de risques de
perdre le fil de pensée entre temps.
Le contexte ici est la compilation d'une application
Non, le contexte c'est ce qu'on était en train de faire quand on s'est rendu compte qu'on avait besoin d'une application ou d'une bibliothèque qui n'est pas installée. Plus l'installation prend du temps, plus il y a de risques de perdre le fil de pensée entre temps.
Nicolas George
Doug713705 , dans le message , a écrit :
Pourri mais fonctionnel.
Encore une fois, non. Juste assez peu cassé pour qu'on n'ait pas envie de le jeter immédiatement.
Il y a quelques années tu l'aurais défendu bec et ongle contre le système d'init de Windows et tu aurais qu'il s'agissait du meilleur sysème d'init du monde.
Non, absolument pas. De mémoire, ça fait un peu moins de quinze ans que je trouve que le système d'init à base de script shells est bancal et aurait besoin d'être repris de fond en comble. Ça a commencé quand j'ai dû reprendre une installation d'un serveur PostgreSQL parce qu'une variable de locale s'était infiltrée insidieusement dans l'initialisation. Seulement à l'époque, personne n'en parlait et je me sentais assez seul.
Doug713705 , dans le message <ct8ijbx4jt.ln2@actarus.redatomik.org>, a
écrit :
Pourri mais fonctionnel.
Encore une fois, non. Juste assez peu cassé pour qu'on n'ait pas envie de le
jeter immédiatement.
Il y a quelques années tu l'aurais défendu bec et ongle contre le
système d'init de Windows et tu aurais qu'il s'agissait du meilleur
sysème d'init du monde.
Non, absolument pas. De mémoire, ça fait un peu moins de quinze ans que je
trouve que le système d'init à base de script shells est bancal et aurait
besoin d'être repris de fond en comble. Ça a commencé quand j'ai dû
reprendre une installation d'un serveur PostgreSQL parce qu'une variable de
locale s'était infiltrée insidieusement dans l'initialisation. Seulement à
l'époque, personne n'en parlait et je me sentais assez seul.
Encore une fois, non. Juste assez peu cassé pour qu'on n'ait pas envie de le jeter immédiatement.
Il y a quelques années tu l'aurais défendu bec et ongle contre le système d'init de Windows et tu aurais qu'il s'agissait du meilleur sysème d'init du monde.
Non, absolument pas. De mémoire, ça fait un peu moins de quinze ans que je trouve que le système d'init à base de script shells est bancal et aurait besoin d'être repris de fond en comble. Ça a commencé quand j'ai dû reprendre une installation d'un serveur PostgreSQL parce qu'une variable de locale s'était infiltrée insidieusement dans l'initialisation. Seulement à l'époque, personne n'en parlait et je me sentais assez seul.
Nicolas George
Benoit Izac , dans le message , a écrit :
Au passage, je constate que tu utilises un lecteur de news qui semble avoir plus de sept d'ans d'âge (ce qui est assez rare de nos jours), j'en déduis donc que toi aussi tu dois avoir de petites habitudes.
J'ai mes habitudes, mais j'ai aussi la capacité de faire la différence entre « ça m'enquiquine parce qu'il faut que je change mes habitudes » et « c'est objectivement pourri ». Je pensais naïvement que cette compétence était plutôt universelle, je suis tristement détrompé.
Benoit Izac , dans le message <874mu1fucl.fsf@izac.org>, a écrit :
Au passage, je constate que tu utilises un lecteur de news qui semble
avoir plus de sept d'ans d'âge (ce qui est assez rare de nos jours),
j'en déduis donc que toi aussi tu dois avoir de petites habitudes.
J'ai mes habitudes, mais j'ai aussi la capacité de faire la différence entre
« ça m'enquiquine parce qu'il faut que je change mes habitudes » et « c'est
objectivement pourri ». Je pensais naïvement que cette compétence était
plutôt universelle, je suis tristement détrompé.
Au passage, je constate que tu utilises un lecteur de news qui semble avoir plus de sept d'ans d'âge (ce qui est assez rare de nos jours), j'en déduis donc que toi aussi tu dois avoir de petites habitudes.
J'ai mes habitudes, mais j'ai aussi la capacité de faire la différence entre « ça m'enquiquine parce qu'il faut que je change mes habitudes » et « c'est objectivement pourri ». Je pensais naïvement que cette compétence était plutôt universelle, je suis tristement détrompé.
Doug713705
Le 15-11-2014, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<5467b9f8$0$2889$) :
D'un autre coté un trou qui permettrait à un utilisateur local qui aurait pris le temps nécessaire de lire la doc relative à un exploit, de coder de quoi réaliser cet exploit afin de faire un DoS ou une escalade de priviliège sur *ma* machine dont je suis le seul utilisateur. Comment dire ?
Dans la sécurité il y a aussi le caclul du risque. Ici le risque est de niveau zéro, je n'ai donc aucune raison de metre à jour.
Note que je ne dis pas qu'il faille esquiver toutes les mise à jour.
Donc tu serais d'accord pour dire que Slackware convient au bricolo qui fait joujou dans sa cave mais pas pour un usage sérieux ?
Non, je dis que _pour ma part_ au moins 2/3 des mises à jours (toutes distribs confondues) ne me concernent pas. C'est tout autant valable que j'utilise Slackware, Debian ou RedHat.
Typiquement, tous les exploits locaux ne me concernent pas. Je suis le seul utilisateur de ma machine et elle n'est pas accessible depuis Internet (modulo l'incompétence notoire de mon FAI qui me fournit une box que je n'ai pas le droit d'administrer et qui est accessible sur le net).
Si je veux absolument mettre ma distribution à jour je peux le faire sans aucun problème.
D'ailleurs elle est à jour ! Seuls les paquets tiers ne le sont pas tous tout simplement parce qu'il est inutile de les mettre à jour.
On ne va pas m'attaquer du jour au lendemain via ffmpeg, blender ou milkytracker, hein ?
À part quelques jeux je n'ai pas d'applications tierses utilisables en réseau depuis internet. Ah si Skype ! Mais ça je ne peux rien y faire c'est un binaire et il est à jour.
La sécurité c'est aussi et surtout bien comprendre ce que fait le système, bien connaitre sa logithèque et certainement pas installer des zillions de paquets en dépendences dont on on ne maitrise rien et dont on ignore jusqu'à leur présence sur le système. Parce que la réalité de terrain, c'est plus ça, hein.
Je ne te parle même pas des paramètres par défauts de ces zillions de paquets et ne me dis pas que Debian est secure par défaut. Openssl se souvient encore que c'est faux.
Tu me diras que c'est un cas particulier, certes, mais si une erreur pareille est passée, permet moi de penser qu'un paramètre par défaut un peu souple peut d'autant plus passer facilement.
Du coup, vérifier cette terachiée de paquets méthodiquement, prends au moins autant de temps que de recompiler de temps à autres un programme pour lequel on choisira soigneusement les options de compilation soi même.
Chacun sa préférence mais s'il te plait ne me parle pas de supériorité de Debian. C'est un pur mythe totalement surfait et usurpé.
Par ailleurs corriger des libs antédiluvienne dont les versions actuelle ont déjà corrigé le problème...
... ce n'est pas bien difficile en général.
J'en suis sincèrement fort heureux.
-- Oh mais laisse allumé bébé, y'a personne au contrôle Et les dieux du radar sont tous out Et toussent et se touchent et se poussent Et se foutent et se mouchent dans la soute à cartouches -- H.F. Thiéfaine, Mathématiques souterraines
Le 15-11-2014, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<5467b9f8$0$2889$426a74cc@news.free.fr>) :
D'un autre coté un trou qui permettrait à un utilisateur local qui
aurait pris le temps nécessaire de lire la doc relative à un exploit,
de coder de quoi réaliser cet exploit afin de faire un DoS ou une
escalade de priviliège sur *ma* machine dont je suis le seul
utilisateur. Comment dire ?
Dans la sécurité il y a aussi le caclul du risque. Ici le risque est
de niveau zéro, je n'ai donc aucune raison de metre à jour.
Note que je ne dis pas qu'il faille esquiver toutes les mise à jour.
Donc tu serais d'accord pour dire que Slackware convient au bricolo qui fait
joujou dans sa cave mais pas pour un usage sérieux ?
Non, je dis que _pour ma part_ au moins 2/3 des mises à jours (toutes
distribs confondues) ne me concernent pas. C'est tout autant valable que
j'utilise Slackware, Debian ou RedHat.
Typiquement, tous les exploits locaux ne me concernent pas.
Je suis le seul utilisateur de ma machine et elle n'est pas accessible
depuis Internet (modulo l'incompétence notoire de mon FAI qui me fournit
une box que je n'ai pas le droit d'administrer et qui est accessible sur
le net).
Si je veux absolument mettre ma distribution à jour je peux le faire
sans aucun problème.
D'ailleurs elle est à jour ! Seuls les paquets tiers ne le sont pas
tous tout simplement parce qu'il est inutile de les mettre à jour.
On ne va pas m'attaquer du jour au lendemain via ffmpeg, blender ou
milkytracker, hein ?
À part quelques jeux je n'ai pas d'applications tierses utilisables en
réseau depuis internet. Ah si Skype ! Mais ça je ne peux rien y faire
c'est un binaire et il est à jour.
La sécurité c'est aussi et surtout bien comprendre ce que fait le
système, bien connaitre sa logithèque et certainement pas installer des
zillions de paquets en dépendences dont on on ne maitrise rien et dont
on ignore jusqu'à leur présence sur le système. Parce que la réalité de
terrain, c'est plus ça, hein.
Je ne te parle même pas des paramètres par défauts de ces zillions de
paquets et ne me dis pas que Debian est secure par défaut. Openssl se
souvient encore que c'est faux.
Tu me diras que c'est un cas particulier, certes, mais si une erreur
pareille est passée, permet moi de penser qu'un paramètre par défaut
un peu souple peut d'autant plus passer facilement.
Du coup, vérifier cette terachiée de paquets méthodiquement, prends au
moins autant de temps que de recompiler de temps à autres un programme
pour lequel on choisira soigneusement les options de compilation soi
même.
Chacun sa préférence mais s'il te plait ne me parle pas de supériorité
de Debian. C'est un pur mythe totalement surfait et usurpé.
Par ailleurs corriger des libs antédiluvienne dont les versions actuelle
ont déjà corrigé le problème...
... ce n'est pas bien difficile en général.
J'en suis sincèrement fort heureux.
--
Oh mais laisse allumé bébé, y'a personne au contrôle
Et les dieux du radar sont tous out
Et toussent et se touchent et se poussent
Et se foutent et se mouchent dans la soute à cartouches
-- H.F. Thiéfaine, Mathématiques souterraines
Le 15-11-2014, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<5467b9f8$0$2889$) :
D'un autre coté un trou qui permettrait à un utilisateur local qui aurait pris le temps nécessaire de lire la doc relative à un exploit, de coder de quoi réaliser cet exploit afin de faire un DoS ou une escalade de priviliège sur *ma* machine dont je suis le seul utilisateur. Comment dire ?
Dans la sécurité il y a aussi le caclul du risque. Ici le risque est de niveau zéro, je n'ai donc aucune raison de metre à jour.
Note que je ne dis pas qu'il faille esquiver toutes les mise à jour.
Donc tu serais d'accord pour dire que Slackware convient au bricolo qui fait joujou dans sa cave mais pas pour un usage sérieux ?
Non, je dis que _pour ma part_ au moins 2/3 des mises à jours (toutes distribs confondues) ne me concernent pas. C'est tout autant valable que j'utilise Slackware, Debian ou RedHat.
Typiquement, tous les exploits locaux ne me concernent pas. Je suis le seul utilisateur de ma machine et elle n'est pas accessible depuis Internet (modulo l'incompétence notoire de mon FAI qui me fournit une box que je n'ai pas le droit d'administrer et qui est accessible sur le net).
Si je veux absolument mettre ma distribution à jour je peux le faire sans aucun problème.
D'ailleurs elle est à jour ! Seuls les paquets tiers ne le sont pas tous tout simplement parce qu'il est inutile de les mettre à jour.
On ne va pas m'attaquer du jour au lendemain via ffmpeg, blender ou milkytracker, hein ?
À part quelques jeux je n'ai pas d'applications tierses utilisables en réseau depuis internet. Ah si Skype ! Mais ça je ne peux rien y faire c'est un binaire et il est à jour.
La sécurité c'est aussi et surtout bien comprendre ce que fait le système, bien connaitre sa logithèque et certainement pas installer des zillions de paquets en dépendences dont on on ne maitrise rien et dont on ignore jusqu'à leur présence sur le système. Parce que la réalité de terrain, c'est plus ça, hein.
Je ne te parle même pas des paramètres par défauts de ces zillions de paquets et ne me dis pas que Debian est secure par défaut. Openssl se souvient encore que c'est faux.
Tu me diras que c'est un cas particulier, certes, mais si une erreur pareille est passée, permet moi de penser qu'un paramètre par défaut un peu souple peut d'autant plus passer facilement.
Du coup, vérifier cette terachiée de paquets méthodiquement, prends au moins autant de temps que de recompiler de temps à autres un programme pour lequel on choisira soigneusement les options de compilation soi même.
Chacun sa préférence mais s'il te plait ne me parle pas de supériorité de Debian. C'est un pur mythe totalement surfait et usurpé.
Par ailleurs corriger des libs antédiluvienne dont les versions actuelle ont déjà corrigé le problème...
... ce n'est pas bien difficile en général.
J'en suis sincèrement fort heureux.
-- Oh mais laisse allumé bébé, y'a personne au contrôle Et les dieux du radar sont tous out Et toussent et se touchent et se poussent Et se foutent et se mouchent dans la soute à cartouches -- H.F. Thiéfaine, Mathématiques souterraines
Nicolas George
Doug713705 , dans le message , a écrit :
D'ailleurs elle est à jour ! Seuls les paquets tiers ne le sont pas tous tout simplement parce qu'il est inutile de les mettre à jour.
Je comptais répondre en détail, mais en relisant ça, j'arrête, c'est juste ridicule. En écrivant ça, tu te disqualifie complètement pour pour toute discussion tournant autour de la sécurité.
Doug713705 , dans le message <ri2ljbxdjs.ln2@actarus.redatomik.org>, a
écrit :
D'ailleurs elle est à jour ! Seuls les paquets tiers ne le sont pas
tous tout simplement parce qu'il est inutile de les mettre à jour.
Je comptais répondre en détail, mais en relisant ça, j'arrête, c'est juste
ridicule. En écrivant ça, tu te disqualifie complètement pour pour toute
discussion tournant autour de la sécurité.
D'ailleurs elle est à jour ! Seuls les paquets tiers ne le sont pas tous tout simplement parce qu'il est inutile de les mettre à jour.
Je comptais répondre en détail, mais en relisant ça, j'arrête, c'est juste ridicule. En écrivant ça, tu te disqualifie complètement pour pour toute discussion tournant autour de la sécurité.
Doug713705
Le 16-11-2014, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<5468832f$0$2373$) :
D'ailleurs elle est à jour ! Seuls les paquets tiers ne le sont pas tous tout simplement parce qu'il est inutile de les mettre à jour.
Je comptais répondre en détail, mais en relisant ça, j'arrête, c'est juste ridicule. En écrivant ça, tu te disqualifie complètement pour pour toute discussion tournant autour de la sécurité.
Tu penses ce que tu veux. Je gère la sécurité de ma machine en fonction de l'utilisation qui en est faite.
Sur le même principe je ne gère pas mon serveur de la même manière que ma machine perso car il n'est pas exposé au même niveau de risques.
Pour revenir à ma machine perso libre à toi de penser que je puisse me faire pwner en utilisant Geany, Blender ou ffmpeg mais il y a un moment où il faut arréter de se tripatouiller la nouille.
Je n'habite pas dans un abri anti-nucléaire au prétexte qu'un Américain un peu trop con, un Russe un peu trop bourré ou un Anglais un peu trop perfide pourrait nous envoyer un ICBM sur la tête.
Je lis les CVE et si ça me semble important j'applique immédiatement le correctif. Dans le cas contraire, je remets ça à plus tard jusqu'au jour où je fais une màj plus profonde de l'ensemble du système parce que, là d'un coup, ça me chante de le faire ou parce que je finis par me dire que ça commence à faire beaucoup de trous pour un gruyère qui n'est pas sensé en avoir.
Alors oui, dans l'absolu ma machine est plus vulnérable mais dans les faits elle n'est pas plus attaquée.
Note que je ne dis pas non plus que mon exemple est à suivre.
-- Et tu remontes à contrecoeur L'escalier de service Tu voudrais qu'y ait des ascenseurs Au fond des précipices -- H.F. Thiéfaine, Mathématiques souterraines
Le 16-11-2014, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<5468832f$0$2373$426a74cc@news.free.fr>) :
D'ailleurs elle est à jour ! Seuls les paquets tiers ne le sont pas
tous tout simplement parce qu'il est inutile de les mettre à jour.
Je comptais répondre en détail, mais en relisant ça, j'arrête, c'est juste
ridicule. En écrivant ça, tu te disqualifie complètement pour pour toute
discussion tournant autour de la sécurité.
Tu penses ce que tu veux. Je gère la sécurité de ma machine en fonction
de l'utilisation qui en est faite.
Sur le même principe je ne gère pas mon serveur de la même manière
que ma machine perso car il n'est pas exposé au même niveau de risques.
Pour revenir à ma machine perso libre à toi de penser que je puisse me
faire pwner en utilisant Geany, Blender ou ffmpeg mais il y a un
moment où il faut arréter de se tripatouiller la nouille.
Je n'habite pas dans un abri anti-nucléaire au prétexte qu'un Américain
un peu trop con, un Russe un peu trop bourré ou un Anglais un peu trop
perfide pourrait nous envoyer un ICBM sur la tête.
Je lis les CVE et si ça me semble important j'applique immédiatement le
correctif. Dans le cas contraire, je remets ça à plus tard jusqu'au jour
où je fais une màj plus profonde de l'ensemble du système parce que, là
d'un coup, ça me chante de le faire ou parce que je finis par me dire
que ça commence à faire beaucoup de trous pour un gruyère qui n'est pas
sensé en avoir.
Alors oui, dans l'absolu ma machine est plus vulnérable mais dans les
faits elle n'est pas plus attaquée.
Note que je ne dis pas non plus que mon exemple est à suivre.
--
Et tu remontes à contrecoeur
L'escalier de service
Tu voudrais qu'y ait des ascenseurs
Au fond des précipices
-- H.F. Thiéfaine, Mathématiques souterraines
Le 16-11-2014, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<5468832f$0$2373$) :
D'ailleurs elle est à jour ! Seuls les paquets tiers ne le sont pas tous tout simplement parce qu'il est inutile de les mettre à jour.
Je comptais répondre en détail, mais en relisant ça, j'arrête, c'est juste ridicule. En écrivant ça, tu te disqualifie complètement pour pour toute discussion tournant autour de la sécurité.
Tu penses ce que tu veux. Je gère la sécurité de ma machine en fonction de l'utilisation qui en est faite.
Sur le même principe je ne gère pas mon serveur de la même manière que ma machine perso car il n'est pas exposé au même niveau de risques.
Pour revenir à ma machine perso libre à toi de penser que je puisse me faire pwner en utilisant Geany, Blender ou ffmpeg mais il y a un moment où il faut arréter de se tripatouiller la nouille.
Je n'habite pas dans un abri anti-nucléaire au prétexte qu'un Américain un peu trop con, un Russe un peu trop bourré ou un Anglais un peu trop perfide pourrait nous envoyer un ICBM sur la tête.
Je lis les CVE et si ça me semble important j'applique immédiatement le correctif. Dans le cas contraire, je remets ça à plus tard jusqu'au jour où je fais une màj plus profonde de l'ensemble du système parce que, là d'un coup, ça me chante de le faire ou parce que je finis par me dire que ça commence à faire beaucoup de trous pour un gruyère qui n'est pas sensé en avoir.
Alors oui, dans l'absolu ma machine est plus vulnérable mais dans les faits elle n'est pas plus attaquée.
Note que je ne dis pas non plus que mon exemple est à suivre.
-- Et tu remontes à contrecoeur L'escalier de service Tu voudrais qu'y ait des ascenseurs Au fond des précipices -- H.F. Thiéfaine, Mathématiques souterraines
Nicolas George
Doug713705 , dans le message , a écrit :
Tu penses ce que tu veux. Je gère la sécurité de ma machine en fonction de l'utilisation qui en est faite.
Tu fais ce que tu veux avec ta machine, mais je n'avais pas remarqué que « la machine de Doug713705 » était l'objet de cette discussion.
Doug713705 , dans le message <skfmjbx8oa.ln2@actarus.redatomik.org>, a
écrit :
Tu penses ce que tu veux. Je gère la sécurité de ma machine en fonction
de l'utilisation qui en est faite.
Tu fais ce que tu veux avec ta machine, mais je n'avais pas remarqué que
« la machine de Doug713705 » était l'objet de cette discussion.
Tu penses ce que tu veux. Je gère la sécurité de ma machine en fonction de l'utilisation qui en est faite.
Tu fais ce que tu veux avec ta machine, mais je n'avais pas remarqué que « la machine de Doug713705 » était l'objet de cette discussion.
Erwan David
Nicolas George <nicolas$ écrivait :
Doug713705 , dans le message , a écrit :
Pourri mais fonctionnel.
Encore une fois, non. Juste assez peu cassé pour qu'on n'ait pas envie de le jeter immédiatement.
Il y a quelques années tu l'aurais défendu bec et ongle contre le système d'init de Windows et tu aurais qu'il s'agissait du meilleur sysème d'init du monde.
Non, absolument pas. De mémoire, ça fait un peu moins de quinze ans que je trouve que le système d'init à base de script shells est bancal et aurait besoin d'être repris de fond en comble. Ça a commencé quand j'ai dû reprendre une installation d'un serveur PostgreSQL parce qu'une variable de locale s'était infiltrée insidieusement dans l'initialisation. Seulement à l'époque, personne n'en parlait et je me sentais assez seul.
Si seulement systemd était juste un système d'iunit : mais ça fait passer emacs pour un one line...
-- Les simplifications c'est trop compliqué
Nicolas George <nicolas$george@salle-s.org> écrivait :
Doug713705 , dans le message <ct8ijbx4jt.ln2@actarus.redatomik.org>, a
écrit :
Pourri mais fonctionnel.
Encore une fois, non. Juste assez peu cassé pour qu'on n'ait pas envie de le
jeter immédiatement.
Il y a quelques années tu l'aurais défendu bec et ongle contre le
système d'init de Windows et tu aurais qu'il s'agissait du meilleur
sysème d'init du monde.
Non, absolument pas. De mémoire, ça fait un peu moins de quinze ans que je
trouve que le système d'init à base de script shells est bancal et aurait
besoin d'être repris de fond en comble. Ça a commencé quand j'ai dû
reprendre une installation d'un serveur PostgreSQL parce qu'une variable de
locale s'était infiltrée insidieusement dans l'initialisation. Seulement à
l'époque, personne n'en parlait et je me sentais assez seul.
Si seulement systemd était juste un système d'iunit : mais ça fait
passer emacs pour un one line...
Encore une fois, non. Juste assez peu cassé pour qu'on n'ait pas envie de le jeter immédiatement.
Il y a quelques années tu l'aurais défendu bec et ongle contre le système d'init de Windows et tu aurais qu'il s'agissait du meilleur sysème d'init du monde.
Non, absolument pas. De mémoire, ça fait un peu moins de quinze ans que je trouve que le système d'init à base de script shells est bancal et aurait besoin d'être repris de fond en comble. Ça a commencé quand j'ai dû reprendre une installation d'un serveur PostgreSQL parce qu'une variable de locale s'était infiltrée insidieusement dans l'initialisation. Seulement à l'époque, personne n'en parlait et je me sentais assez seul.
Si seulement systemd était juste un système d'iunit : mais ça fait passer emacs pour un one line...
-- Les simplifications c'est trop compliqué
Lucas Levrel
Le 15 novembre 2014, Nicolas George a écrit :
On dirait que tu as raté mon message du 13 à 22:08 où je liste une partie des défauts des scripts façons rc.d.
Effectivement c'était un peu noyé dans la masse.
Tant mieux, rc.d c'est pourri : des scripts shell fragiles qui dupliquent chacun les fonctionnalités nécessaires, des services qui se retrouvent à hériter de l'environnement de l'utilisateur qui les a relancés, des bouts de services qui continuent à tourner après l'arrêt et j'en passe.
- est-ce que la fragilité est inhérente au fait que ce soient des scripts, ou une constatation sur (la plupart de) ces scripts ? - la duplication n'est pas forcément une tare ; - l'héritage en question est-il inévitable ? - idem, les résidus sont-ils inévitables ou dus à des erreurs des auteurs des scripts ?
-- LL
Le 15 novembre 2014, Nicolas George a écrit :
On dirait que tu as raté mon message du 13 à 22:08 où je liste une partie
des défauts des scripts façons rc.d.
Effectivement c'était un peu noyé dans la masse.
Tant mieux, rc.d c'est pourri : des scripts shell fragiles qui dupliquent
chacun les fonctionnalités nécessaires, des services qui se retrouvent à
hériter de l'environnement de l'utilisateur qui les a relancés, des bouts de
services qui continuent à tourner après l'arrêt et j'en passe.
- est-ce que la fragilité est inhérente au fait que ce soient des scripts,
ou une constatation sur (la plupart de) ces scripts ?
- la duplication n'est pas forcément une tare ;
- l'héritage en question est-il inévitable ?
- idem, les résidus sont-ils inévitables ou dus à des erreurs des auteurs
des scripts ?
On dirait que tu as raté mon message du 13 à 22:08 où je liste une partie des défauts des scripts façons rc.d.
Effectivement c'était un peu noyé dans la masse.
Tant mieux, rc.d c'est pourri : des scripts shell fragiles qui dupliquent chacun les fonctionnalités nécessaires, des services qui se retrouvent à hériter de l'environnement de l'utilisateur qui les a relancés, des bouts de services qui continuent à tourner après l'arrêt et j'en passe.
- est-ce que la fragilité est inhérente au fait que ce soient des scripts, ou une constatation sur (la plupart de) ces scripts ? - la duplication n'est pas forcément une tare ; - l'héritage en question est-il inévitable ? - idem, les résidus sont-ils inévitables ou dus à des erreurs des auteurs des scripts ?
