totof2000 a écrit 9656 commentaires

Absolment pas. On a remplacé un principe simple par une usine a gaz sous pretexte que des gens aiment compliquer les choses. Les trucs de démarrage à la systemd, ça parait beau sur le papier, mais à l'usage on se trouve avec des trucs moisis qui explosent sans qu'on sache pourquoi. C'est typiquement le genre de truc qui font que je déteste autant Windows. Plus ça vient et moins j'aime Linux. Quel gachis.

Les 42 000 options que l'on peut insérer dans systemd sont loin d'être claires. Avec un script tu vois rapidement ce qui se passe. Ca nécessite de connaitre un peu la programmation shell (au moins savoir lire un script), mais au moins on voit du premier coup d'oeil ce qui se passe.

Après il y a les guignols qui passent leur temps à compliquer les choses, à décomposer un script en trois ou quatre scripts s'appelant les uns les autres, mais là ce n'est pas le systme d'init qu'il faut mettre en cause mais les gens qui ne savent pas s'en servir.

J'espère que tu n'as pas pris le "3 ou 4 lignes" au pied de la lettre quand même.

Le problème de la résistance au changement, c'est qu'on demande au truc nouveau des choses qu'on ne demandais pas à ce qu'on a l'habitude d'utiliser.

Quels trucs et pour quelle utilité ?

Tu me dis que les scripts étaient compliqués. Soit, mais dans ce cas, pourquoi ne pas écrire des scripts simples ?

Décris-le moi en 3 ou 4 lignes. La doc de systemd me donne mal à la tête.

GNI ? Tu voudrais donc que systemd te permette d'écrire tes scripts de démarrage comme un goret et de mettre en place des services pourris ? C'est bien ce que je dis, les gens qui veulent ça veulent un windows.

Plutot que de casser un GNU/linux, pourquoi ne pas redévelopper un widows libre ?

Arrêtez avec cette histoire de temps de démarrage, c'est ridicule car ce n'est qu'une conséquence de l'architecture de systemd et non le but voulu à la base.

Quel est donc le but voulu alors ?

Tu peux trouver pas mal de personnes qui expliqueront ses possibilités et te diront que c'est confortable dans de très nombreux cas.

Je veux des exemples. Pour l'instant les personnes qui me l'ont expliqué ne m'ont pas convaincues.

Mais merci d'arrêter ce fud sur systemd, croire que c'est pour gagner du temps au démarrage montre que vous ne connaissez pas systemd en fait et que du coup votre argumentation contre lui est biaisé (oui quand on ignore 95% des possibilités d'un logiciel, on ne peut se permettre de le critiquer sur le sujet…).

Si ces 95% de possibilités sont inutiles, ….

Ne serait-ce donc pas plutôtles scripts compliqués qui aurait fallu changer ?

Comment faire pour configurer un nouveau service non intégré dans la distrib ?

un SGBD qui doit être démarré avant les autres services mais qui prend des plombes, faut faire un sleep dans le script c'est crade.

??? En quoi SystemD règle-t-il ce problème ? Et si le script de démarrage du SGBD rend la main avant que le SGBD ne soit démarré, ne serait-ce pas plutot le script de démarrage de SGBD qu'il faudrait réécrire plutot que l'ensemble du process de démarrage du système ?

Oui car systemd, comme d'autres technologies, sont souvent critiqués sur des bases de philosophie informatiques fumeuses et rarement avec des arguments techniques intéressants. Au contraire, systemd répond à de nombreuses problématiques, que tout le monde passe sous silence, et suffisamment pour que les distributions l'adoptent volontairement (et donc sans contrainte).

Avant systemd : un système de scripts System5 simple à comprendre :
- /etc/init.d/monscript start
/etc/init.d/monscript stop
/etc/init.d/monscript status
- un lien dans /etc/rcN.d vers le script en question avec tous les scripts qui commencent par K pour arret, et S pour start et un chiffre indiquant l'ordre de démarrage.

Aujourd'hui, avec systemd : un tas de fichiers de conf dans tous les sens avec des liens partout, dans lesquels on ne comprend pas grand chose. Il suffit de lire le dernier linux mag pour se faire une idée de l'horreur (ça m'a donné envie de vomir ce truc). On en arrive à un truc immonde ressemblant d'assez près aux services Windows. On perd un certain contrôle par rapport à la simplicité de System5 tout ça pour gagner quelques secondes au démarrage.

Pour un desktop, à la limite, pourquoi pas, mais pour un serveur, non merci.

Là je vois juste un changement pour le changement, rien d'autre. Je suis prêt à changer d'avis, mais pour l'instant les arguments en faveur de SystemD ne m'ont pas convaincus. Si tu en as je suis preneur.

Pas ce que je veux : je ne peux pas lier le binaire simultanément à mad et à une bibliothèque incompatible avec la GPL.
Si tu fais ce que tu veux. La GPL s'applique à la diffusion.

Donc si je suis ton raisonnement, ton code sous licence MIT devient du code GPL, le code BSD lié à ton code MIT devient aussi GPL, et si ce code BSD est un code de bas niveau et qui est lié à la quasi totalité de FreeBSD ou NEtBSD, tout FreeBSD et NetBSD devient GPL et tout les programmes proprio utilisant du code BSD issu de FreeBSD et/ou NetBSD deviennent GPL c'est ca ?

Ton raisonnement ne tient pas.

Donc, si par défaut mon player inclus un support (et rien que ça — pas de code) mad, je ne peux le lier qu'à des bibliothèques compatibles avec la GPL et les changements de licences éventuels ne peuvent se faire que vers des licences de ce type. De fait, en l'état (ie. sauf à dégager le support mad), il se retrouve donc en GPL.

Tu fais ce que tu veux, tu n'as juste pas le droit de distribuer l'ensemble sous GPL.

larté de ces arguments qui m'ont per

HEIN ????????????

Non, non et encore non : la GPL ne contamine pas ton code non GPL. Quelle idée étrange.

seule la compilation va en faire du code GPL.
Non.

Aucune importance, la question initiale est celle de la viralité. Le fait est que mon code se retrouve sous GPL sans que ce soit mon choix et sans que j'inclue autre chose que des appels de fonctions (pas le code GPL en tant que tel — on est àmha bien au-delà de la réciprocité).

Ton code ne se trouve jamais sous GPL. Ton code reste sous licence BSD.

Absolument pas. Du code GPL modifié doit être mis à disposition sous GPL, point barre.

Et ? En quoi un code GPL lié à un code BSD modifie-t-il le code GPL ?

Résultat, je peux continuer à distribuer mon code sous MIT, qui est mon choix de licence initial, mais si une distro propose le paquet compilé avec le support mad, celui-ci sera sous GPL. Tu le vois le côté viral, là ?

Pourquoi ?

Le code source GPL reste GPL, et le code source BSD reste sous BSD. La distribution de l'exécutable par une distribution impose de fournir les sources des programmes liés au code GPL, mais ne change en rien la licence du code source BSD. C'est pour ça qu'on parle de licence compatible.

???? C'est à dire ?

Rectificatif : Ah pardon on me signale qu'il y a malentendu

Avec PulseAudio ? M'etonne pas, on entend rien avec ce truc.

Achète un MAC …

---->[]

Merci, je vais tenter … sinon je vais devoir me résoudre à mettre en place un NAS pour déposer/récupérer les fichiers …

De même j'ai un collègue qui vient au travail en trebuchet
Il se casse la figure tout le long du trajet  ? Il devrait s'acheter une canne …

Ton aisance à manier l'humour pince-sans-rire me laisse coi

Te laisse quoi ?