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'autant plus que dans le cas de systemd on enlève ta montre à aguilles sans que tu n'aies rien demandé pour t'en donner une digitale qui ne fonctionne pas tout à fait et dont les fonctionnalités changent tous les 4 matins. Et si tu protestes c'est que tu es un anti-progressiste, un refractaire, un con, un mec qui veut assassiner Poettering.
Malheureusement, les utilisateurs sont toujours à la merci des « visions » des fabricants. Et ça n'est pas propre à l'informatique...
-- LL
Le 16 novembre 2014, Doug713705 a écrit :
D'autant plus que dans le cas de systemd on enlève ta montre à aguilles
sans que tu n'aies rien demandé pour t'en donner une digitale qui ne
fonctionne pas tout à fait et dont les fonctionnalités changent tous les
4 matins. Et si tu protestes c'est que tu es un anti-progressiste, un
refractaire, un con, un mec qui veut assassiner Poettering.
Malheureusement, les utilisateurs sont toujours à la merci des « visions »
des fabricants. Et ça n'est pas propre à l'informatique...
D'autant plus que dans le cas de systemd on enlève ta montre à aguilles sans que tu n'aies rien demandé pour t'en donner une digitale qui ne fonctionne pas tout à fait et dont les fonctionnalités changent tous les 4 matins. Et si tu protestes c'est que tu es un anti-progressiste, un refractaire, un con, un mec qui veut assassiner Poettering.
Malheureusement, les utilisateurs sont toujours à la merci des « visions » des fabricants. Et ça n'est pas propre à l'informatique...
-- LL
Lucas Levrel
Le 15 novembre 2014, Nicolas George a écrit :
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.
Ta dernière phrase n'est pas incompatible avec la définition de « fonctionnel ». On peut s'asseoir sur un tabouret bancal ; ce n'est pas optimal mais ça n'oblige pas à rester debout.
-- LL
Le 15 novembre 2014, Nicolas George a écrit :
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.
Ta dernière phrase n'est pas incompatible avec la définition de
« fonctionnel ». On peut s'asseoir sur un tabouret bancal ; ce n'est pas
optimal mais ça n'oblige pas à rester debout.
Encore une fois, non. Juste assez peu cassé pour qu'on n'ait pas envie de le jeter immédiatement.
Ta dernière phrase n'est pas incompatible avec la définition de « fonctionnel ». On peut s'asseoir sur un tabouret bancal ; ce n'est pas optimal mais ça n'oblige pas à rester debout.
-- LL
Nicolas George
Lucas Levrel , dans le message , a écrit :
- est-ce que la fragilité est inhérente au fait que ce soient des scripts, ou une constatation sur (la plupart de) ces scripts ?
Inhérente : le shell est un langage extrêmement souple et léger pour les cas simples, mais la fragilité est la contrepartie de cette souplesse.
- la duplication n'est pas forcément une tare ;
Si, car elle exige que les erreurs soient réparées à tous les endroits.
- l'héritage en question est-il inévitable ?
En théorie, non. En pratique, oui, car le shell ne propose aucune infrastructure pour récupérer un environnement au sens large propre, et parce que le nombre d'éléments héritables est énorme (et dépend du système) : les variables d'environnement, les fd ouverts, le chemin courant, les limites douces et dures, l'umask, les namespaces, la personnalité, le type et la priorité du scheduling, la même chose pour les I/O, le terminal de contrôle, les masques de signaux. J'en oublie certainement.
- idem, les résidus sont-ils inévitables ou dus à des erreurs des auteurs des scripts ?
Faire une faute en copiant cent pages de texte dans une langue inconnue, est-ce inévitable ou dû à une erreur de la part du copiste ?
Lucas Levrel , dans le message
<alpine.LNX.2.11.1411171055010.1685@localhost>, a écrit :
- est-ce que la fragilité est inhérente au fait que ce soient des scripts,
ou une constatation sur (la plupart de) ces scripts ?
Inhérente : le shell est un langage extrêmement souple et léger pour les cas
simples, mais la fragilité est la contrepartie de cette souplesse.
- la duplication n'est pas forcément une tare ;
Si, car elle exige que les erreurs soient réparées à tous les endroits.
- l'héritage en question est-il inévitable ?
En théorie, non. En pratique, oui, car le shell ne propose aucune
infrastructure pour récupérer un environnement au sens large propre, et
parce que le nombre d'éléments héritables est énorme (et dépend du
système) : les variables d'environnement, les fd ouverts, le chemin courant,
les limites douces et dures, l'umask, les namespaces, la personnalité, le
type et la priorité du scheduling, la même chose pour les I/O, le terminal
de contrôle, les masques de signaux. J'en oublie certainement.
- idem, les résidus sont-ils inévitables ou dus à des erreurs des auteurs
des scripts ?
Faire une faute en copiant cent pages de texte dans une langue inconnue,
est-ce inévitable ou dû à une erreur de la part du copiste ?
- est-ce que la fragilité est inhérente au fait que ce soient des scripts, ou une constatation sur (la plupart de) ces scripts ?
Inhérente : le shell est un langage extrêmement souple et léger pour les cas simples, mais la fragilité est la contrepartie de cette souplesse.
- la duplication n'est pas forcément une tare ;
Si, car elle exige que les erreurs soient réparées à tous les endroits.
- l'héritage en question est-il inévitable ?
En théorie, non. En pratique, oui, car le shell ne propose aucune infrastructure pour récupérer un environnement au sens large propre, et parce que le nombre d'éléments héritables est énorme (et dépend du système) : les variables d'environnement, les fd ouverts, le chemin courant, les limites douces et dures, l'umask, les namespaces, la personnalité, le type et la priorité du scheduling, la même chose pour les I/O, le terminal de contrôle, les masques de signaux. J'en oublie certainement.
- idem, les résidus sont-ils inévitables ou dus à des erreurs des auteurs des scripts ?
Faire une faute en copiant cent pages de texte dans une langue inconnue, est-ce inévitable ou dû à une erreur de la part du copiste ?
Nicolas George
Lucas Levrel , dans le message , a écrit :
Ta dernière phrase n'est pas incompatible avec la définition de « fonctionnel ». On peut s'asseoir sur un tabouret bancal ; ce n'est pas optimal mais ça n'oblige pas à rester debout.
Dis ça à tous ceux qui sont tombés parce qu'ils ont relâché leur attention un peu trop longtemps.
Lucas Levrel , dans le message
<alpine.LNX.2.11.1411171107260.1685@localhost>, a écrit :
Ta dernière phrase n'est pas incompatible avec la définition de
« fonctionnel ». On peut s'asseoir sur un tabouret bancal ; ce n'est pas
optimal mais ça n'oblige pas à rester debout.
Dis ça à tous ceux qui sont tombés parce qu'ils ont relâché leur attention
un peu trop longtemps.
Ta dernière phrase n'est pas incompatible avec la définition de « fonctionnel ». On peut s'asseoir sur un tabouret bancal ; ce n'est pas optimal mais ça n'oblige pas à rester debout.
Dis ça à tous ceux qui sont tombés parce qu'ils ont relâché leur attention un peu trop longtemps.
Michel
Le 17/11/2014 13:03, Nicolas George a écrit :
Lucas Levrel , dans le message , a écrit :
Ta dernière phrase n'est pas incompatible avec la définition de « fonctionnel ». On peut s'asseoir sur un tabouret bancal ; ce n'est pas optimal mais ça n'oblige pas à rester debout.
Dis ça à tous ceux qui sont tombés parce qu'ils ont relâché leur attention un peu trop longtemps.
Prenez des tabourets à trois pieds, difficile d'être bancal avec trois pieds ;)
Michel
Le 17/11/2014 13:03, Nicolas George a écrit :
Lucas Levrel , dans le message
<alpine.LNX.2.11.1411171107260.1685@localhost>, a écrit :
Ta dernière phrase n'est pas incompatible avec la définition de
« fonctionnel ». On peut s'asseoir sur un tabouret bancal ; ce n'est pas
optimal mais ça n'oblige pas à rester debout.
Dis ça à tous ceux qui sont tombés parce qu'ils ont relâché leur attention
un peu trop longtemps.
Prenez des tabourets à trois pieds, difficile d'être bancal avec trois
pieds ;)
Ta dernière phrase n'est pas incompatible avec la définition de « fonctionnel ». On peut s'asseoir sur un tabouret bancal ; ce n'est pas optimal mais ça n'oblige pas à rester debout.
Dis ça à tous ceux qui sont tombés parce qu'ils ont relâché leur attention un peu trop longtemps.
Prenez des tabourets à trois pieds, difficile d'être bancal avec trois pieds ;)
Michel
yamo'
Salut,
Nicolas George a écrit le 14/11/2014 14:52 :
Non, c'est parce que le système actuel est pourri que systemd est mieux.
Je suis sur Debian Jessie/unstable sans avoir touché à la conf de systemd et donc sur systemd depuis un moment et franchement pour le desktop, je n'ai pas vu de bug à part lors des grosses mises à jours de testing et où je devais relancer les process concernés pour que ça revienne à la normale.
En tant que serveur, je ne suis pas joueur.
-- Stéphane Passerelle web en version alpha : <http://nemo.pasdenom.info>
Salut,
Nicolas George a écrit le 14/11/2014 14:52 :
Non, c'est parce que le système actuel est pourri que systemd est mieux.
Je suis sur Debian Jessie/unstable sans avoir touché à la conf de
systemd et donc sur systemd depuis un moment et franchement pour le
desktop, je n'ai pas vu de bug à part lors des grosses mises à jours de
testing et où je devais relancer les process concernés pour que ça
revienne à la normale.
En tant que serveur, je ne suis pas joueur.
--
Stéphane
Passerelle web en version alpha : <http://nemo.pasdenom.info>
Non, c'est parce que le système actuel est pourri que systemd est mieux.
Je suis sur Debian Jessie/unstable sans avoir touché à la conf de systemd et donc sur systemd depuis un moment et franchement pour le desktop, je n'ai pas vu de bug à part lors des grosses mises à jours de testing et où je devais relancer les process concernés pour que ça revienne à la normale.
En tant que serveur, je ne suis pas joueur.
-- Stéphane Passerelle web en version alpha : <http://nemo.pasdenom.info>
