Que tu n'aies pas le problème ne rend pas le problème moins réel pour autant.
Non, ça veut juste dire qu'il ne concerne que toi.
Et je trouve assez incroyable que tu blames les daemons générant les logs quand un système de log scale mal. Syslog est parfaitement capable de traiter le volume de donnée.
Pour ma part je trouve assez incroyable que tu blâmes journald alors que le problème vient de chez toi. Il "scale" bien ailleurs, notamment sur de multiples serveurs.
Et je ne blâmais pas les daemons en général, mais un daemon supposément mal écrit.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Qui plus est, il fait cela en remplaçant des fichiers texte par des fichiers binaires qui ont ensuite besoin de programmes spéciaux pour être manipulés. Comme modifier /etc/locale.conf au lieu d'appeler localtcl.
Seul le journal est binaire.
Devrait se lire ainsi :
Qui plus est, il fait cela en remplaçant des fichiers texte par des fichiers binaires qui ont ensuite besoin de programmes spéciaux pour être manipulés.
Seul le journal est binaire. Pour le reste, on peut par exemple modifier /etc/locale.conf directement au lieu d'appeler localtcl.
Mais je ne peux plus corriger ! grrr.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Je pense que le reproche principal qu'on peut faire à systemd est que c'est quelque-chose qui s'éloigne complètement de l'esprit Unix:
Faux. systemd c'est une soixantaine de binaire, tous remplaçables et on peut tous éviter de les utiliser (sauf le coeur, évidemment), voire de les compiler.
petits composants logiciels qui font une seule chose et la font bien
Voir au dessus.
communication entre ces composants pour obtenir des choses plus complexes
Voir au dessus.
utilisation de fichiers texte directement lisibles et modifiables par les utilisateurs
On peut éviter d'utiliser ces binaires pour modifier la config et modifier les fichiers texte cibles à la main à la place.
Systemd ne se contente pas d'être un remplaçant à init et de gérer le démarrage du système et des divers démons, il vise aussi à remplacer syslog,
Non, c'est journald qui remplace syslog.
gérer automatiquement les devices dans /dev,
Non, ça reste le rôle de udev.
etc…
etc quoi ?
Qui plus est, il fait cela en remplaçant des fichiers texte par des fichiers binaires qui ont ensuite besoin de programmes spéciaux pour être manipulés. Comme modifier /etc/locale.conf au lieu d'appeler localtcl.
Seul le journal est binaire.
Fini les commandes tail -f /var/log/messages ou le grep dans maillog.
En même temps, journald fournit tout ce qu'il faut pour analyser le journal (man journalctl). Et il fournit un journal au format standardisé (fini les 26 formats de dates différents, par exemple).
Et on peut toujours reverser le contenu du journal de journald sous forme texte vers syslog (ça reverse dans les deux sens, en fait, avec le daemon approprié).
Fini le débugage de scripts de démarrage avec vi.
Tant mieux :
Myth: systemd is not debuggable.
False. Some people try to imply that the shell was a good debugger. Well, it isn't really. In systemd we provide you with actual debugging features instead. For example: interactive debugging, verbose tracing, the ability to mask any component during boot, and more. Also, we provide documentation for it.
It's certainly well debuggable, we needed that for our own development work, after all. But we'll grant you one thing: it uses different debugging tools, we believe more appropriate ones for the purpose, though.
Et puis les unit files sont bien plus simples, et ils sont uniformisés (idéalement, l'unit file provient de l'upstream du projet, et non pas de la distribution)
On se retrouve avec une usine à gaz qui met en l'air 30 ans de pratiques industrielles et je ne suis pas sûr qu'on gagne quelque-chose en échange.
On y gagne énormément en échange. Quelques exemples :
* Hotplug support
* Démarrage bien plus rapide
* Compatibilité avec les shellscripts
* Support du multi-seat
* systemd est scriptable ( systemctl, loginctl, timedatectl, hostnamectl, localectl , …)
* Arrêt bien plus fiable des services (fini les zombies) grâce aux cgroups du kernel
* Intégration avec Linux (comme l'init BSD est fait pour BSD)
* unification des unit files (plutôt que d'avoir 36 variantes du script d'init pour un même logiciel, un par distrib'…)
* unification des runlevels (fini les différences à ce niveau entre les distributions)
* on ne réinvente pas la roue : systemd utilise linux, udev, d-bus, tout ce qui existait déjà.
Quant aux versions plus récentes :
Le support de XP fut de 13 ans (c'est une exception dû au retard énorme du projet Longhorn/Vienna qui a finit par un accouchement douloureux de Vista) (2001 - 2014)
Le support de Windows 7 est de 11 ans (2009 - 2020. Pour le moment).
Le support de Windows 8 est pour le moment de 10 ans (2013 - 2023).
En revanche, c'est clairement plus long dans le monde de l'embarqué, comme Windows 3.11 Embedded qui a terminé sa vie en 2011, ou Windows XP Embedded qui finira sa vie en 2016 après 15 ans de service.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
hormis pour les collectionneurs, une vieille machine a maintenant peu d'interet
D'abord ça évite parfois d'acheter une nouvelle machine, surtout si on a des besoins basiques, et surtout si on considère qu'une machine de ~2 ans est déjà vieille pour pas mal de monde (hélas).
À part ça, elle peut avoir un intérêt par rapport à l'histoire de l'informatique.
Elle peut avoir un intérêt en tant que machine pour vieilles applications et jeux.
Elle peut avoir un intérêt sentimental/nostalgique (histoire personnelle).
Elle peut avoir un intérêt pour faire des expérimentations logicielles et matérielles sur une machine non-critique.
Elle peut avoir un intérêt au sein d'un réseau privé/amateur en tant que serveur perso (serveur de fichiers, par exemple).
Elle peut avoir un intérêt pour les pièces détachées (cartes filles, CPU …).
…
Bref, réfléchissons bien avant de jeter par habitude consumériste.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Je dis sûrement une connerie (n'utilisant pas de DE ni de gestionnaire de connexion) mais je crois que systemd est une dépendance des truckKit.
systemd remplace consolekit, et n'a pas pour dépendance, ni n'est une dépendance de, policykit.
C'est aussi une dépendance de dbus ( ça c'est sûr par contre, j'ai libsystemd-login0 installé à cause de dbus, ici… et dire que dbus ne me sers à rien… groumpf)
dbus sert pourtant à beaucoup d'applications. Avoir un système de messages entre applications, c'est pas franchement révolutionnaire (les autres OS font pareil) ni honteux, hein. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Ben oui c'est propre, systemd est modulaire (il est fourni avec une 60aine de binaires qui sont tous des utilitaires, on peut l'utiliser sans ou les remplacer).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Ubuntu s'en passe bien avec un upstart compatible au niveau de l'API pour que les parties de Gnome utilisant l'API de systemd fonctionnent tout pareil sans systemd.
Mais bon, comme toujours, ça ne fonctionne pas en râlant sur linuxfr.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Ben c'est un architecture client/serveur, faut s'habituer à la logique de DRb.
Mais comme DRb fournit tout, le surcoût en ligne de codes est léger.
Après il y a d'autres manières de faire du multiprocess (IO.popen, par exemple), mais c'est bien plus fait pour juste lancer une commande.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Another reason why invalid passwords take longer to reject is to reduce the effectiveness of dictionary attacks. If invalid passwords were rejected just as quickly as valid passwords were accepted, then a bad guy could just churn through a dictionary trying out invalid passwords at high speed. Adding a delay of a few seconds before rejecting invalid passwords introduces a minor inconvenience to users who mistyped their passwords, but makes a huge dent in stopping dictionary attacks. For example (and these numbers are completely made up), suppose you have a 75,000 word password dictionary, and passwords are accepted or rejected in 100ms. It would take a little over three hours to attempt every password in the dictionary. Introducing even a simple 5-second delay into the rejection of invalid passwords increases the time to perform a dictionary search to over four days.
Il y a aussi une règle (réglable dans gpedit.msc) qui permet de spécifier à partir de combien de tentatives foirées on bloque la machine, et pour combien de temps (typiquement, 30 minutes).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Lors de mon enfance ET tout le long de mon adolescence. Sais-tu lire ?
Je sais pas où tu étais dans les années 1990, voire tout début années 2000, mais les disquettes étaient encore là et bien là.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
une icône a un sens évident (pour celui qui l'a dessinée): qui parmi les moins de 40 ans a déjà vu "en vrai" une disquette 720k sous étui rigide, symbole "universel" de l'action d' ECRIRE (et non sauvegarder) un DOCUMENT (et non un fichier)?
Euh moi, 28 ans, qui en a vu plein lors de mon enfance / adolescence. Les disquettes 3 pouces et demi étaient encore très présentes dans les années 1990. Donc pas besoin d'avoir 40 ans.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Ruby, pour ce que j'en ai vue est très utilisé pour le développement web (avec un framework, on est pas maso), l'administration serveur et quelques outils cli. (c'est un langage qui à l'air pratique à l'usage)
Ben tous ces langages sont plutôt généralistes, à la fois de part leur conception et les bibliothèques disponibles. Par exemple, pour Ruby, certes Ruby est surtout connue à travers Ruby On Rails, mais rien n'empêche le langage d'être utilisé pour tout et n'importe quoi (sauf les environnements où on ne peut avoir la VM Ruby, comme l'embarqué. Ou pour les applications où Ruby serait jugé trop lent.).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mon opinion sur systemd
Posté par xcomcmdr . En réponse à la dépêche Entretien avec François Tigeot, développeur DragonFly BSD. Évalué à 9.
Je ne vois pas en quoi le choix du C serait mauvais.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Utiliser syslog avec systemd
Posté par xcomcmdr . En réponse à la dépêche Entretien avec François Tigeot, développeur DragonFly BSD. Évalué à 1.
Non, ça veut juste dire qu'il ne concerne que toi.
Pour ma part je trouve assez incroyable que tu blâmes journald alors que le problème vient de chez toi. Il "scale" bien ailleurs, notamment sur de multiples serveurs.
Et je ne blâmais pas les daemons en général, mais un daemon supposément mal écrit.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Utiliser syslog avec systemd
Posté par xcomcmdr . En réponse à la dépêche Entretien avec François Tigeot, développeur DragonFly BSD. Évalué à 0.
Pas chez moi (ASUS X71SL), ni sur mon netbook (ASUS 1005 HA).
Peut-être un service qui génère trop d'entrées dans le journal, en permanence ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C’est du propre
Posté par xcomcmdr . En réponse à la dépêche Entretien avec François Tigeot, développeur DragonFly BSD. Évalué à 2.
Oui, on a dégainé en même temps ! :o
En plus j'ai pourri une citation. Ceci :
Devrait se lire ainsi :
Mais je ne peux plus corriger ! grrr.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C’est du propre
Posté par xcomcmdr . En réponse à la dépêche Entretien avec François Tigeot, développeur DragonFly BSD. Évalué à 10. Dernière modification le 26 octobre 2013 à 17:26.
Faux. systemd c'est une soixantaine de binaire, tous remplaçables et on peut tous éviter de les utiliser (sauf le coeur, évidemment), voire de les compiler.
:)
Voir au dessus.
Voir au dessus.
On peut éviter d'utiliser ces binaires pour modifier la config et modifier les fichiers texte cibles à la main à la place.
Non, c'est journald qui remplace syslog.
Non, ça reste le rôle de udev.
etc quoi ?
Seul le journal est binaire.
En même temps, journald fournit tout ce qu'il faut pour analyser le journal (man journalctl). Et il fournit un journal au format standardisé (fini les 26 formats de dates différents, par exemple).
Et on peut toujours reverser le contenu du journal de journald sous forme texte vers syslog (ça reverse dans les deux sens, en fait, avec le daemon approprié).
Tant mieux :
Et puis les unit files sont bien plus simples, et ils sont uniformisés (idéalement, l'unit file provient de l'upstream du projet, et non pas de la distribution)
On y gagne énormément en échange. Quelques exemples :
* Hotplug support
* Démarrage bien plus rapide
* Compatibilité avec les shellscripts
* Support du multi-seat
* systemd est scriptable ( systemctl, loginctl, timedatectl, hostnamectl, localectl , …)
* Arrêt bien plus fiable des services (fini les zombies) grâce aux cgroups du kernel
* Intégration avec Linux (comme l'init BSD est fait pour BSD)
* unification des unit files (plutôt que d'avoir 36 variantes du script d'init pour un même logiciel, un par distrib'…)
* unification des runlevels (fini les différences à ce niveau entre les distributions)
* on ne réinvente pas la roue : systemd utilise linux, udev, d-bus, tout ce qui existait déjà.
Bref, tu devrais lire ceci :
http://0pointer.de/blog/projects/the-biggest-myths.html
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Bis repetita placent
Posté par xcomcmdr . En réponse à la dépêche Étude de Mozilla comparant les taux de compression de différents formats d'images. Évalué à 5.
What is this, I don't even ??
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par xcomcmdr . En réponse à la dépêche Après 101 tours de jeu, fin de partie pour le noyau 3.0.x. Évalué à 4. Dernière modification le 26 octobre 2013 à 16:12.
Oui ben même chez MS c'est dans ces eaux là, pas beaucoup plus, contrairement à ce qu'on pourrait croire.
Le support de Windows 3.11 fut de 8 ans. (1993 - 2001)
Le support de Windows 95 fut de 6 ans. (1995 - 2001)
Le support de Windows 98 fut de 8 ans. (1998 - 2006)
Le support de Windows ME fut de 6 ans. (2000 - 2006)
Le support de Windows 2000 fut de 10 ans. (2000 - 2010)
Le support de Windows NT 4 fut de de 8 ans. (1996 - 2004)
Et enfin, 11 ans pour Vista
Quant aux versions plus récentes :
Le support de XP fut de 13 ans (c'est une exception dû au retard énorme du projet Longhorn/Vienna qui a finit par un accouchement douloureux de Vista) (2001 - 2014)
Le support de Windows 7 est de 11 ans (2009 - 2020. Pour le moment).
Le support de Windows 8 est pour le moment de 10 ans (2013 - 2023).
En revanche, c'est clairement plus long dans le monde de l'embarqué, comme Windows 3.11 Embedded qui a terminé sa vie en 2011, ou Windows XP Embedded qui finira sa vie en 2016 après 15 ans de service.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Migrer c'est chiant
Posté par xcomcmdr . En réponse à la dépêche Open Bar Microsoft/Défense : des documents confirment les jeux de pouvoir et la décision politique. Évalué à 2.
Les logiciels libres ont aussi des EOL.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Viellesse et consommation
Posté par xcomcmdr . En réponse à la dépêche Donnez une seconde jeunesse à votre ordinosaure, le samedi 26 octobre 2013 à Draguignan. Évalué à 3.
Bah quelqu'un qui l'utilise avec l'OS de l'époque et les applications de l'époque.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: HTML5
Posté par xcomcmdr . En réponse au journal C'est au tour de Wireshark de passer à Qt. Évalué à 10.
" If all you have is a hammer, everything looks like a nail."
-_-'
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Viellesse et consommation
Posté par xcomcmdr . En réponse à la dépêche Donnez une seconde jeunesse à votre ordinosaure, le samedi 26 octobre 2013 à Draguignan. Évalué à 4. Dernière modification le 21 octobre 2013 à 19:56.
D'abord ça évite parfois d'acheter une nouvelle machine, surtout si on a des besoins basiques, et surtout si on considère qu'une machine de ~2 ans est déjà vieille pour pas mal de monde (hélas).
À part ça, elle peut avoir un intérêt par rapport à l'histoire de l'informatique.
Elle peut avoir un intérêt en tant que machine pour vieilles applications et jeux.
Elle peut avoir un intérêt sentimental/nostalgique (histoire personnelle).
Elle peut avoir un intérêt pour faire des expérimentations logicielles et matérielles sur une machine non-critique.
Elle peut avoir un intérêt au sein d'un réseau privé/amateur en tant que serveur perso (serveur de fichiers, par exemple).
Elle peut avoir un intérêt pour les pièces détachées (cartes filles, CPU …).
…
Bref, réfléchissons bien avant de jeter par habitude consumériste.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Je croyais qu'on pourrait se passer de systemd si on le voulait ....
Posté par xcomcmdr . En réponse au journal Ayé c'te fois : GNOME 3.8 est dans Debian Sid (mais attention). Évalué à 4.
systemd remplace consolekit, et n'a pas pour dépendance, ni n'est une dépendance de, policykit.
dbus sert pourtant à beaucoup d'applications. Avoir un système de messages entre applications, c'est pas franchement révolutionnaire (les autres OS font pareil) ni honteux, hein. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Je croyais qu'on pourrait se passer de systemd si on le voulait ....
Posté par xcomcmdr . En réponse au journal Ayé c'te fois : GNOME 3.8 est dans Debian Sid (mais attention). Évalué à 2.
Ben oui c'est propre, systemd est modulaire (il est fourni avec une 60aine de binaires qui sont tous des utilitaires, on peut l'utiliser sans ou les remplacer).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Je croyais qu'on pourrait se passer de systemd si on le voulait ....
Posté par xcomcmdr . En réponse au journal Ayé c'te fois : GNOME 3.8 est dans Debian Sid (mais attention). Évalué à 3.
Ubuntu s'en passe bien avec un upstart compatible au niveau de l'API pour que les parties de Gnome utilisant l'API de systemd fonctionnent tout pareil sans systemd.
Mais bon, comme toujours, ça ne fonctionne pas en râlant sur linuxfr.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ben voyons
Posté par xcomcmdr . En réponse à la dépêche GNU Make 4.0 extensible. Évalué à 1.
Sauf que cette backdoor n'a jamais été intégrée au code officiel du noyau.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: bashing du D
Posté par xcomcmdr . En réponse à la dépêche Présentation de Rust 0.8. Évalué à 3.
"aujourd'hui", suffit (et c'est déjà un pléonasme, techniquement !).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Du pourquoi du GIL
Posté par xcomcmdr . En réponse à la dépêche Sortie de Rubinius 2.0. Évalué à 3.
Ben c'est un architecture client/serveur, faut s'habituer à la logique de DRb.
Mais comme DRb fournit tout, le surcoût en ligne de codes est léger.
Après il y a d'autres manières de faire du multiprocess (IO.popen, par exemple), mais c'est bien plus fait pour juste lancer une commande.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: limiter les esssais ?
Posté par xcomcmdr . En réponse au journal La proche fin des mots de passe. Évalué à 3.
D'ailleurs, c'est ce que fait Windows lors du login depuis au moins Windows 2000.
Il y a aussi une règle (réglable dans gpedit.msc) qui permet de spécifier à partir de combien de tentatives foirées on bloque la machine, et pour combien de temps (typiquement, 30 minutes).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Nvidia travaille avec Valve
Posté par xcomcmdr . En réponse au journal Hypocrisie de Nvidia envers le libre : le pilote graphique Linux volontairement dégradé ?. Évalué à 4.
Sur la Gamecube et la Wii, y'a le logo d'ATI…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Du pourquoi du GIL
Posté par xcomcmdr . En réponse à la dépêche Sortie de Rubinius 2.0. Évalué à 4. Dernière modification le 07 octobre 2013 à 23:18.
J'ai fait du multiprocessing avec Ruby 1.9 et DRb : http://www.ruby-doc.org/stdlib-2.0.0/libdoc/drb/rdoc/DRb.html
Ça m'a permis d'exploiter deux cores en même temps.
Après, ce n'est pas un strict équivalent, mais c'est possible au moins de faire du multiprocessing.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: KDE Plasma Active 4
Posté par xcomcmdr . En réponse à la dépêche Plasma Active 4. Évalué à 8.
Lors de mon enfance ET tout le long de mon adolescence. Sais-tu lire ?
Je sais pas où tu étais dans les années 1990, voire tout début années 2000, mais les disquettes étaient encore là et bien là.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: KDE Plasma Active 4
Posté par xcomcmdr . En réponse à la dépêche Plasma Active 4. Évalué à 8.
Euh moi, 28 ans, qui en a vu plein lors de mon enfance / adolescence. Les disquettes 3 pouces et demi étaient encore très présentes dans les années 1990. Donc pas besoin d'avoir 40 ans.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Oui mais...
Posté par xcomcmdr . En réponse à la dépêche Sortie de Rubinius 2.0. Évalué à 5. Dernière modification le 07 octobre 2013 à 20:21.
define "langage de script".
Python et Ruby (souvent décrits "langages de scripts") sont avant tout des langages orientés objet, et multi-paradigmes.
Ce n'est pas l'usage traditionnel du langage qui définit les possibilités du langage.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Oui mais...
Posté par xcomcmdr . En réponse à la dépêche Sortie de Rubinius 2.0. Évalué à 4.
Ben tous ces langages sont plutôt généralistes, à la fois de part leur conception et les bibliothèques disponibles. Par exemple, pour Ruby, certes Ruby est surtout connue à travers Ruby On Rails, mais rien n'empêche le langage d'être utilisé pour tout et n'importe quoi (sauf les environnements où on ne peut avoir la VM Ruby, comme l'embarqué. Ou pour les applications où Ruby serait jugé trop lent.).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Précautions
Posté par xcomcmdr . En réponse au message Débutante qui requiert des conseils . Évalué à 6.
Avant tout, soit sûre d'avoir sauvegardé toutes tes données (sur clé USB, disque dur externe, ou autre).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)