xcomcmdr a écrit 3537 commentaires

Je ne parle même pas des vaccins

Tant mieux, car dire que les vaccins sont dangereux est ridicule.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Euh… moi je me trimballais une dizaine de feuilles de papier et un bic… ça suffisait.

Super, des feuilles volantes. Pour rien retenir, c'est sûr, ça suffit.

J'avais des cahiers, une trousse, et des livres bien lourds.

Quand j'étudiais en informatique, j'avais un ordi (essaie de compiler avec une feuille et un bic ;-)), et c'était non seulement indispensable, mais aussi bien moins lourd.

Voire quasi inexistant (une clé USB) si tu utilisais les ordis de l'école sur place.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Faut arrêter d'être binaire !

J'utilise Archlinux tous les jours.

Mais ce n'est pas pour autant que je méprise le reste.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

En quoi était-elle de mauvais goût ?

Elle était tout à fait justifié, quoi qu'en disent les Apple fanboys !

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Je n'ai pas 'appris' a utiliser Windows

Bullshit.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

WUT ?

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

pas mal, mais c'est plus rapide au souris/clavier. Surtout face à un zerg rush…

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Quand j'ai eu ce problème (le SSD / disque dur ne se "lançait" pas au retour de veille/hibernation), c'était le kernel linux qui n'était plus compatible avec la config de mon BIOS (je cite ci-dessous la doc ubuntu sur l'ASUS X71SL) :

Bios > Security > I/O interface security > option New card interface —> mettre en statut LOCKED au lieu de UNLOCKED
Model de laptop cité dans le topic avec le même problème : ASUS-F81SE, ASUS-X71SLseries(le mien), ASUS F50S, ASUS N90

Bref, faudrait fouiller dans ton BIOS pour voir (ça vaut aussi pour l'auteur du journal).

Quant à systemd, je ne vois pas vraiment le rapport. C'est le kernel et le BIOS qui gèrent au final l'ACPI, pas systemd.

Ce how-to, assez vieux, est quand même intéressant d'un point de vue technique je trouve :
https://forums.gentoo.org/viewtopic.php?t=122145

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Tu fais quoi ici à part déverser ton mépris de linux et de sa communauté ?

Ah oui, rien.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

systemd

Systemd n'est pas plus complexe pour un débutant. Oui, il a plus de lignes de code, mais il s'administre tout aussi aisément (voire plus facilement, je pense notamments aux units qui s'écrivent en 30 secondes alors que j'ai jamais été très adepte du shell), et avec plus de fiabilité (systemd m'informe bien mieux sur l'état des services, et les contrôlent sans s'embêter grâce aux control groups du kernel).

Quand à l'usage au quotidien : d'abord, il n'y a pas de raison pour un débutant d'avoir plus affaire à systemd qu'il n'avait affaire à SysV. Si ça marche (et 99% du temps sytemd est fiable), le débutant n'y verra que du feu.

Au niveau de l'implémentation, systemd est compatible avec les scripts. Mais ça, ça concerne plus les mainteneurs que l'usager débutant.

Au niveau des commandes, avant on utilisait systemctl, après on utilise… systemctl.
poweroff/halt/reboot etc sont même toujours bien compris.

Bref, non seulement le passage à systemd est transparent (comme ce sera le cas quand Ubuntu y passera) mais en plus celui qui touche à systemctl, c'est difficile de le décrire comme débutant.

git

git est moins simple que svn, mais offre bien plus que svn. Des fonctionnalités si utiles que personne ne veut repasser à SVN.

le système de packaging Debian

Il est plus complexe que d'autres, mais il offre plus facilement certains services que pacman. Par exemple :

Display packages which conflict with given expression (often package). Search can be used as well to mimic this function.

(none) repoquery --whatconflicts aptitude search '~Cpattern' IN PROGRESS

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

tout ce qui est entre signe inférieur/signe supérieur ne s'affiche pas, du coup le message a parfois un sens assez différent. Si un modérateur pouvait passer par là pour enlever ces signes…. Merci !

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Je serai curieux de savoir le nom des logiciels du même type des distributions utilisant d'autres systèmes de packages?

Pour Archlinux :
Pacman et pkgfile (qui utilise les métadonnées de pacman et dépend de pacman)

Quelques exemples :

à quoi sert le paquet

pacman -[S|Q]i[i] <foo>

(notamment la ligne "Description")

l'état du paquet

J'imagine si c'est pour savoir s'il est installé ou non. Là je trouve que ce n'est pas très direct

1. pacman -Qs <package_pas_local> ne renvoie rien (ça veut dire qu'il n'est pas installé)
2. pacman -Qi <package_pas_local> propose la complétion chez moi. Si pas de complétion ou erreur comme quoi le paquet n'a pas été trouvé, pas installé

Pour le reste des infos, la commande pacman -Qi[i] <bar> remplit bien son office.
Il y a aussi la commande pacman -Qk <bar> pour vérifier un paquet, ou pacman -Qkk pour tous les vérifier.

pourquoi est-il, ou non, installé

pacman -[S|Q]i[i] <bar>
(notamment la ligne "Motif d'installation")

Quant à savoir pourquoi il n'est pas installé, je ne vois pas le but ni la commande. On peut savoir les conflits avec -[Q|S]ii <foo> mais sinon…

Après, il y aussi la page Pacman Tips qui liste pas mal de scripts/one-liners/outils tiers pour étendre/compléter pacman.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

T'as un wifi du bus (pci ;-)) ?!
La classe americaine!

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Ou Flash pas assez stable pour supporter l'excellence de Linux. ;-)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Oulà, t"en tiens une couche…

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Plus besoin d'être root ?

Pour poweroff/reboot/hibernate/mise en veille, il faut "juste" faire partie du groupe power. Mais pour halt :

max-laptop% halt
Must be root.
max-laptop% type halt
halt is /usr/bin/halt
max-laptop% ls -l /usr/bin/halt
lrwxrwxrwx 1 root root 9 1 sept. 19:42 /usr/bin/halt -> systemctl
max-laptop% groups
adm lp wheel rfkill games network video audio optical storage power users vboxusers systemd-journal bumblebee networkmanager lpadmin camera libvirt
max-laptop% systemctl halt
Failed to start halt.target: Access denied

(archlinux, donc j'utilise systemd)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Et puis bon le nombre de lignes ça a un intérêt très limité, mais si tu vas par là :
T'as regardé le nombre de lignes du kernel, de xorg, de firefox, de chrome ?

Tous en font bien bien plus que /lib/systemd/systemd. OH MY GOD ! :o
Et Xorg tourne en root !

Mais non, c'est systemd le pire parmi les SPOFs présents. Va comprendre…

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Le sysvinit ne fait (quasi) plus rien après le boot… Est-ce le cas de systemd ?

Bah oui. /usr/bin/init (qui est un lien vers /lib/systemd/systemd) ne s'occupe que du boot. Le reste est ailleurs (systemctl, journalctl, …)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Et sysV c'est pas un SPOF peut-être ?

Par ailleurs, le code de l'init (/usr/bin/systemd) est très réduit.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

une fois qu'on sera tous passé à systemd, il se passe quoi si systemd se "plante" pour une raison X ou Y ?

Normalement, tu récupères un shell si tu as CrashShell à 1 dans /etc/systemd/system.conf (je n'arrive pas à trouver si l'option est déjà à 1 par défaut ou non)
Tu peux aussi récupérer un coredump avec l'option DumpCore

systemd [OPTIONS…]

Starts up and maintains the system or user services.

-h --help Show this help
--test Determine startup sequence, dump it and exit
--no-pager Do not pipe output into a pager
--dump-configuration-items Dump understood unit configuration items
--unit=UNIT Set default unit
--system Run a system instance, even if PID != 1
--user Run a user instance
--dump-core[=0|1] Dump core on crash
--crash-shell[=0|1] Run shell on crash
--confirm-spawn[=0|1] Ask for confirmation when spawning processes
--show-status[=0|1] Show status updates on the console during bootup
--log-target=TARGET Set log target (console, journal, kmsg, journal-or-kmsg, null)
--log-level=LEVEL Set log level (debug, info, notice, warning, err, crit, alert, emerg)
--log-color[=0|1] Highlight important log messages
--log-location[=0|1] Include code location in log messages
--default-standard-output= Set default standard output for services
--default-standard-error= Set default standard error output for services

Note que j'ai jamais eu de crash de systemd qui ne soit pas à cause d'un problème de configuration de ma part (grand classique : une erreur de frappe dans /etc/fstab).

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

systemctl status wpa_supplicant
journalctl --unit wpa_supplicant
journalctl --unit wpa_supplicant -xn
journalctl /usr/bin/foo

man journalctl

Aussi, tous les outils de systemd proposent la complétion. Ainsi, je suis tombé sur cette liste d'options :

max-laptop% journalctl --unit wpa_supplicant -
Completing option
--after-cursor —Start showing entries from after the specified cursor
--all -a —Show all fields, including long and unprintable

--boot -b —Show data only from the specified boot or offset

--catalog -x —Show explanatory texts with each log line

--cursor -c —Start showing entries from the specified cursor

--directory -D —Show journal files from directory

--disk-usage —Show total disk usage

--dmesg -k —Show only kernel messages from the current boot

--dump-catalog —Dump messages in catalog

--field -F —List all values a certain field takes

--file —Operate on specified journal files

--follow -f —Follow journal

--force —Force recreation of the FSS keys

--full -l —Show long fields in full

--header —Show journal header information

--help -h —Show this help

--interval —Time interval for changing the FSS sealing key

--lines -n —Number of journal entries to show

--list-boots —List boots ordered by time

--list-catalog —List messages in catalog

--merge -m —Show entries from all available journals

--new-id128 —Generate a new 128 Bit ID

--no-pager —Do not pipe output into a pager

--no-tail —Show all lines, even in follow mode

--output -o —Change journal output mode

--pager-end -e —Jump to the end of the journal in the pager

--priority -p —Show only messages within the specified priority rang
--quiet -q —Don't show privilege warning

--reverse -r —Reverse output

--root —Operate on catalog hierarchy under specified director
--setup-keys —Generate a new FSS key pair

--since —Start showing entries on or newer than the specified
--system —Show system and kernel messages

-u —Show data only from the specified unit

--until —Stop showing entries on or older than the specified d
--update-catalog —Update binary catalog database

--user —Show messages from user services

--user-unit —Show data only from the specified user session unit

--verify —Verify journal file consistency

--verify-key —Specify FSS verification key

--version —Show package version

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Sous Archlinux + KDE, Firefox 32 (venant des dépôts officiels pour Archlinux), et quelques extensions :

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Et c'est pour ça que le mythe de la relecture linuxien/LL : "c'est du code relu par tout le monde, donc de qualité" c'est pour les gogos.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Ahah, très drôle. Sauf que c'est à côté de la plaque.

Il l'a relu après que la faille soit dans la nature depuis des années, exploitée, et exploitable.

Normalement, le but de la relecture de code, c'est d'éviter les failles. Pas de les découvrir après que le code ait été écrit et déployé en faisant "oops!".

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Sa "came" est alléchante et bien présentée, et logique.

On peut pas en dire autant de 99% des trolls anti-systemd anti-Lennart.

Basically there was System V Init, and earth was pure and the youth respected the elders. Then came upstartd and systemd and one of them brought sin into the world. It escalated a bit and by now everybody agrees that we need to burn a witch, but there is some disagreement which one.

;-)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)