GnunuX a écrit 1072 commentaires

Par contre sur la dernière mise à jour, Firefox empêche les recherche en affichant un dialogue bloquant invitant à "restaurer les paramètres de recherche par défaut" (qqch du genre).

Je n'ai pas eu ce dialogue alors.

Merci de confirmer. Je ne me souviens pas avoir changé quoi que ce soit alors que qwant lite est toujours mon moteur par défaut et j'ai encore ma zone de recherche.

on arrive sur un petit menu qui nous propose une console root …

Et voir le message :

give root password for maintenance
(or press Control-D to continue)

Vaut mieux éditer dans grub et rajouter "init=/bin/bash" dans ce cas là.

J'ai déjà "tout" ou presque dans mon navigateur; Vidéo ( je consomme beaucoup de streaming, Yt, NFlx, ..); Musique, j'utilise mon Subsonic maison (ou Yt ..); J'ai également des lecteurs de documents en ligne dans des onglets,une console ssh (web-console fait bien le taf, ça empêche pas d'avoir un terminal d'ouvert non plus pour bourriner un peu plus), mes éventuels Torrents sont également géné via wTransmission, j'oublie les outils dit "cloud" tout ça …

Mouef, tu as des applications web extérieurs qui font tout cela. Ce n'est pas firefox qui gère la collection de musique, le ssh, …

Si tu veux un webmail, installe un webmail pour rester cohérent.

Par exemple un Firebug ne pourrais être refait avec le nouveau système.

Ce n'est pas firefox 57 qui signe la mort de Firebug. Il est mort depuis que Firefox a intégrer des outils identique.

J'entends les remarques sur les actions obsolète, moi je trouve bien qu'on me dise les permissions demandées pour chaque extension. Avant, toute les extensions avaient accès à tout, sans dire ce qu'ils utilisent comme informations.

Ce débat me fait penser au passage à systemd. Quasi tout le monde trouve que les fonctionnalités apportées sont un plus. Mais quelques grincheux anime le débat sur le sujet.

Lire cet article (en anglais), https://www.krackattacks.com/ éventuellement à la suite de cette lecture, passer à BSD

Lisons donc l'article …

During our initial research, we discovered ourselves that Android, Linux, Apple, Windows, OpenBSD, MediaTek, Linksys, and others

Bien bien bien …

alors quand tout ça est réuni

Même pas ! Il faut aussi que tu utilise systemd-resolved.

Le reste, je ne sais pas, et/ou ne vois pas nécessairement l'utilité (différents usages, différents besoins).

systemctl is-system-running : te dis si le système est complètement démarré et sans erreur (c'est quand le minimum qu'on puisse demander)
systemclt status xxx == service xxx status
systemctl edit xxxx : te permet de personnaliser un script d'init
systemctl set-environment xxx : te permet de setter de variable d'environnement

Je pourrais rajouter à la liste :

systemd-cgls pour voir le contenu des cgroups
systemd-cgtop pour l'usage des ressources des cgroups à la top
systemd-analyze plot > plot.svg : pour avoir les graphs de démarrage en svg

Et plein de détail dont je ne pense pas là tout de suite.

Tu fais référence à quel argument ?
Le coup du "c'est juste que vous ne voulez pas apprendre".

C'est marrant comme remarque :) Ma phrase faisait référence à la phrase que tu as écrite :

Si je comprend bien, tu t'es formé à systemd, et pas au mécanisme de journalisation de la distrib en question, et tu râles de ne pas avoir les compétences?

Donc tu me reproches à moi de faire référence à tes propres arguments ?

Très marrant.

D'ac. Du coup, ça se passe comment si dpkg pose une question à l'utilisateur?

dpkg prends la valeur par défaut au question posée si je me souviens bien.

Si j'ai bien compris, tu soupçonnes le pare-feu de faire planter le kernel? Mouai. Et t'as pas les logs? Re-mouai. Je sais pas ce que tu utilises pour configurer ton pare-feu, mais je doute fort que la sortie d'erreur ne soit pas redirigeable vers un fichier.

Moi je n'ai jamais parlé de Kernel. Ma préoccupation était de remettre en place le plus rapidement le serveur. Donc … ben j'ai regardé les fichiers de log modifiés depuis le dernier reboot. Et ben …, rien d'intéressant. Non je n'avais pas envie de modifier des scripts d'init pour avoir plus de log.

J'ai désactivé le service du firewall (au hasard) et j'ai redémarré. J'ai eu accès au serveur. Je n'en sais pas plus malheureusement (est-ce que le firewall étant en cause ? aucune idée).

Avec systemd/journald j'aurais au moins pu savoir quels services étaient démarrés ou non au dernier reboot ainsi que les logs et les status. C'est tout ce que j'ai dit.

Après mon propos était de dire que, pour moi, les apports techniques sont bien évidement a prendre en compte, parce que, pour moi, systemd me simplifie la vie. Pour ne citer que ce qui me passe par la tête : journalctl, systemctl is-system-running, systemclt status xxx, systemctl --state=failed, systemctl edit xxxx, systemctl set-environment xxxx n'ont pas d'équivalent aussi puissant et simple.

La perte de diversité supposée, la personnalité de Lennart, le changement de philosophie, et le reste du blah blah ne me préoccupe pas le moins du monde.

Voila. Donc c'est bien ce que je disais, l'argument que j'ai souvent lu en provenance d'un pro-systemd vers les autres se retourne bien ici.

Tu fais référence à quel argument ?

Le logiciel te demande ce que tu veux faire, typiquement: prendre la version du mainteneur, regarder le diff ou garder ta version.
En tout cas, sous Debian.
Conclusion, il est très possible de générer un diff avant (voire pendant) la MàJ et de porter le diff après la MàJ en ayant accepté au préalable la version du mainteneur.

Effectivement, mais je ne fais jamais les mises à jour à la main mais j'utilise des outils comme "unattended-upgrades".

Je suis d'accord, mais justement les bons scripts d'init affichaient directement une belle erreur. Alors qu'avec systemd, même avec une unit bien écrite, on n'a rien.

Personnellement ça ne me gène pas parce que le "status" donne explicitement les erreurs en cas d'erreur de démarrage. Ca reste rapide pour trouver les messages d'erreurs. Par contre, il faut effectivement 2 commandes.
Il manque peut être une option pour afficher les erreurs au démarrage/arrêt.

Concrètement, qu'est-ce qui empêche les services d'avoir leur stdout/err redirigés par le script d'init (que ce soit sysV ou un autre, on s'en cogne) dans un fichier propre?

Rien. Sauf qu'a priori ce n'est pas fait (puisque je n'ai pas de log).

Il n'y a pas de mécanisme prévu pour que pour je modifie le script d'init tout en conservant les mises à jour (ben oui si tu modifie un fichier dans /etc sous debian/ubuntu il n'est plus mis à jour). Donc j'évite (surtout avec mes faibles compétences en ma possession).

En quoi systemd t'aurais permis de faire ce que tu n'a pas pu faire avec l'init classique ?

La différence c'est qu'avec systemd/journald tu as les logs de tout, chronologique et facilement accessible. Là je n'avais strictement aucun log.

Le problème que j'avais ? Je n'en suis pas bien sûr (pas de log et pas d'accès à l'écran). Ca semble être liée à des règles de firewall qui ne s'appliqueraient pas.

Techniquement, on ne va pas nier qu'il y a des apports. Est-ce le problème ?

Encore la semaine dernière … un serveur dédié qui ne redémarre pas après une mise à jour. Évidement sur un serveur pas sous systemd … Franchement j'ai bien regretté systemd/journald.

On peut toujours discuter du sexe des anges mais les avancées de systemd sont suffisamment important pour justifier son inclusion dans les distributions majeurs.

Tous tes arguments … ce n'est que la rhétorique.

Quelqu’un sait pourquoi cette décision a été prise ? J’ai du mal à voir l’intérêt.

C'est marqué dans le bug original : https://bugzilla.mozilla.org/show_bug.cgi?id=1247056

Make Pulse Audio a hard dependency on Linux so that we reduce the problems and maintenance associated with maintaining multiple audio backends.

les scripts d'init ne sont plus présents

Il faut surtout que tu précises quel script d'init il manque au lieu d'invoquer des théories du complot.

D'ailleurs, c'est beaucoup plus facile de planter le boot d'un système avec sysv…

Par contre, ça j'ai déjà réussi :)

ce qui n'est pas le cas avec systemd

J'en ai fait des conneries dans mes unit, mais jamais au point que le serveur ne démarre pas.

Comment tu t'y es pris ?

Ceux qui ne comprennent pas la philosophie UNIX sont condamnés à la répéter.

Pourquoi tu dis ca ? Pourtant :

• Linux est un noyau léger qui ne fait qu'une chose (enfin je crois) ;
• bash n'est qu'un shell avec peu de fonctionnalité (mais si !) ;
• apache, nginx, … ne font que serveur HTTP (pff faut pas croire ce qui est dit dans la doc d'apache aussi) ;
• emacs, vim ne sont que des éditeurs de texte (ceux qui disent l'inverse mentent !).
• …

Puisqu'on te dit que les outils UNIX ne font qu'une tâche, elles ne font qu'une seule tâche (ou pas).

en disant fuck à DoNotTrack

Le problème de DoNotTrack (et tu le sais très bien) c'est que "le sens exact de « suivre » les internautes restant à définir".

Par exemple :

• les logs apache te "traque", si je fais des logs, je ne respecte pas Do Not Track ?
• si je fais des statistiques sur l'utilisation de mon site web, je ne respecte pas Do Not Track ?
• si je file des informations à un régie publicitaire, … bon ok là je pense que tout le monde est d'accord, je ne respecte pas Do Not Track.

Mozilla donne sa définition de Do Not Track et pense que cela ne concerne que le troisième exemple. Ce n'est pas la tienne (et d'ailleurs pas la même non plus), mais tu ne peux pas dire qu'ils disent "fuck" à Do Not Track.

Pourquoi? OpenGL a su évoluer avec le temps et pourtant il n'y a pas d'alternative.

Ton exemple contredit ce que tu dis plus haut. Il existe plusieurs implémentations d'OpenGL, donc il faut bien plusieurs moteurs HTML, CSS, …

Et on s'étonne de la mort des applis desktop: des toolkits avec moins de features que html5 qui pètent tout à chaque version, un packaging/déploiement de plus en plus compliqué…

Mais bien sûr … il n'y jamais de problème a la mise à jour des libs javascript …

Pour m'obliger à lire son journal.

Ben non tu ne lis pas le journal quand tu fais : "systemctl status nginx"

Pas sûr de bien comprendre le besoin, mais viking pourrait correspondre : https://sourceforge.net/projects/viking/