GnunuX a écrit 1072 commentaires

Parce que désactiver n'est pas stopper.

Donc 3 solutions :

• redémarrer la machine après le systemctl disable gdm.service (beurk)
• arrêter le service avant la désactivation : systemctl stop gdm.service && systemctl disable gdm.service (mouef) ;
• désactiver et stopper en même temps : systemctl disable gdm.service --now

Contenu du man :
```
--now

When used with enable, the units will also be started. When used with disable or mask, the units will also be stopped. The start or stop operation is only carried out when the respective enable or disable operation has been successful.

Comme vous le savez tous, PulseAudio était connu pour être particulièrement populaire pour ces plantages incessants lors de ses débuts

Parce que c'était un projet neuf et donc comme tout projet neuf il y a un bashing inutile sur le projet. 3 gus qui râle sur un twitter ne définit pas un sentiment "populaire". Mais c'est systématique et inévitable malheureusement.

Pour ceux qui connaissait les problèmes audios AVANT PA, je n'ai pas de souvenir négatif de l'arrivé de PA bien au contraire (franchement vu les joies de esd, artsd, alsa, oss, jack, …).

Pour moi PA est une vrai réussite qui a considérablement simplifié et amélioré l'audio sur les distributions.

On peut aussi utiliser systemd pour isolé un service/une commande :

http://0pointer.net/blog/ip-accounting-and-access-lists-with-systemd.html

Et c'est encore pire avec systemd, puisque, la dernière fois que j'ai regardé, tous les processus fils de systemd-init (du projet systemd) avaient un UID de 0…

Regardons …

[root@localhost ~]# ps -e -o ppid:1,user,cmd:200|grep ^"1 "|grep systemd
1 root     /usr/lib/systemd/systemd-journald
1 root     /usr/lib/systemd/systemd-udevd
1 systemd+ /usr/lib/systemd/systemd-timesyncd
1 systemd+ /usr/lib/systemd/systemd-resolved
1 root     /usr/lib/systemd/systemd-logind
1 dbus     /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
1 root     /usr/lib/systemd/systemd-machined
1 gnunux   /usr/lib/systemd/systemd --user

Ok …

je me trompe peut-être

Tu crois ?

Et dire que je croyais que Wayland etait un remplacant de X11…

Pour ma part je n'ai pas pensé que Wayland était en replacant de X11 … Pour moi c'est le remplacement d'une partie de X11, à d'autres projets de fournir les fonctionnalités manquantes nécessaire (c'est le cas avec CUPS, libinput, …).

Pour la transparence réseau … je pense que plus personne ne proposera ce genre de protocole et ce n'est pas forcement un manque, il y a aujourd'hui d'autres techniques plus efficace.

et enleve X11 sur le serveur ca ne marchera pas. Enfin bon…

Et tu penses que si j'enlève le serveur SSH je pourrais encore faire du SSH ?

Comment tu expliques ca :

Re: Problèmes Wayland

J'ai pas compris pourquoi ça fais de moi un complotiste.

Parce que tu considère que si KDE porte son DE sur Wayland c'est à cause de Wayland. Comme si des développeurs de chez Wayland avait la possibilité d'imposer quoique ce soit (ce qui ressemble fortement à une théorie du complot).

Si KDE choisit de porter leur DE sur Wayland c'est qu'il y voit un intérêt.

Donc le seul responsable c'est KDE. Personne n'a la possibilité de les obligés de passer à autre chose (on est bien d'accord ?).

Il y a eu plusieurs projets ayant l'ambition de "remplacer X". Si les autres tentative n'ont pas réussit ce n'est pas pour de mauvaise raison (pression ou je ne sais quoi) mais juste parce qu'il n'était pas convaincant (contrairement à Wayland).

C'est strictement la même chose avec systemd. Le projet est convaincant donc plusieurs distributions ont décidés d'utiliser le projet pour ces avantages.

Ton message au quel je répondais tenter de faire passer une réécriture d'une fonctionnalité pour être compatible avec l'API de Wayland comme n'étant pas de la faute à Wayland.

De la même manière que lorsque systemd arrive est casse de précédentes fonctionnalités c'est de la faute de systemd.

Ah oui j'avais oublié la fameuse théorie du complot qui veux que certains développeurs ont la capacité de terroriser l'ensemble des développeurs pour qu'il utilise leur produit plutôt qu'un autre (pourtant beaucoup mieux !).

Ou l'autre explication rationnelle (mais qui a l’inconvénient de ne pas mettre la faute sur les autres) c'est que et systemd et wayland sont nécessaires pour avoir un système maintenable, modulaire, administrable et moderne. Poussé par ces avantages, les gens commencent a l'utiliser.

Bon après, un horde de complotistes, cacher derrière leur clavier, en mode consommateur pure, se plaignent que cela change leurs habitudes … mais cela c'est une autre histoire.

Ce n'est pas lié aux mondes du libre tu me diras, ils ont les mêmes problèmes chez microsoft et apple.

de partage bureau fiable (à la ssh -X) sous Wayland.

Par exemple … avec ssh -X ?

Je suis sous Wayland :

root 1044 0.0 0.0 447472 8876 ? Ssl févr.09 0:00 /usr/sbin/gdm
root 25185 0.0 0.0 379900 12916 ? Sl 20:06 0:00 \_ gdm-session-worker [pam/gdm-password]
gnunux 25228 0.0 0.0 390732 11856 tty2 Ssl+ 20:06 0:00 \_ /usr/libexec/gdm-wayland-session /usr/bin/gnome-session
Et … :

root 20442 0.0 0.0 12664 7604 ? Ss févr.11 0:00 /usr/sbin/sshd -D -oCiphers=aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes256-cbc,aes12
root 27171 0.2 0.0 14460 9312 ? Ss 20:08 0:00 \_ sshd: gnunux [priv]
gnunux 27179 0.0 0.0 14460 5460 ? S 20:08 0:00 \_ sshd: gnunux@pts/2
gnunux 27191 0.2 0.0 218520 5892 pts/2 Ss 20:08 0:00 \_ -bash
gnunux 27301 5.8 0.2 565360 41840 pts/2 Sl+ 20:08 0:00 \_ gnome-calculator


Enfin, utiliser une distribution basée sur un truc qui ressemble de plusen plus à un bloatware immonde (systemd pour ne pas le nommer), ben non, merci.

Ca me fait juste penser à https://hooktube.com/watch?v=6AeWu1fZ7bY

Voilà voila.

Le design est fait de comme en 1998

Ca tombe bien, le design a été fait en 1998.

Si cela venait réellement de systemd, comment tu justifie le message ci-dessus ? :

Sans systemd, on a exactement la même chose:

# service burp status
burp disabled; edit /etc/default/burp
# echo $?
0

J'avoue que je ne comprends pas du tout ce que tu essai de dire. Chaque changement dans Debian à partir de maintenant peut être lié à systemd ? C'est assez … confus …

Il me semble qu'il a justement bien pris soin de ne pas mettre ça sur le dos de systemd.

Oui mais il laisse entendre qu'il y a un lien entre ce changement de comportement et systemd. Alors que visiblement cela n'a strictement rien a voir.

Contribuer à Debian plutôt que faire des fork… L'ancien système fonctionne encore !

Sauf que tu auras toujours la bibliothèque impure "libsystemd0" d'installé sur ton système. I N A D M I S S I B L E qu'on te dis.

Le problème est plus dans l'appriori de refuser d'installer un programme KDE sous prétexte de conserver une pureté imaginaire.

Les gens font bien ce qu'ils veulent sur leur PC, non ? Je ne comprends pas bien en quoi c'est un "problème".

Moi je pertinance !

c'est comme si l'état français achetait 40K€ des voitures à 15K€ à un nouveau constructeur

Et fournissait les plans du moteur, …

Ouais enfin faut pas oublié que Space X est fortement subventionné.

Après c’est peut être une autre façon de travailler qui ne te convient pas, mais moi j’utilise les signets pour qu’ils soient facilement accessibles dans la recherche.

Par exemple si je mets un signet sur un dossier nommé "developpement", j’ai juste à faire "Alt-f1" et taper "developpement" (enfin le début du mot) pour qu’il apparaisse dans la section "Fichier" de la recherche.

Cela me semble bien plus efficace et rapide que de passer par le bureau.

Gnome Shell est utilisable au clavier ET de façon avancée depuis 7 ans!
[..]
Heureusement que les dev Gnome ont la peau dure avec tout ce qu'ils ont pris dans la gueule.

Je me suis fait exactement la même remarque. J'utilise Gnome 3 depuis les début et il a toujours été facilement utilisable au clavier (bien plus que Gnome 2).

se debarasser de cette architecture moisie x86 compatible Intel.

heuuuu … c'est en contradiction avec "Ces deux failles sont liées à l’architecture des processeurs modernes (Intel, AMD, ARM, etc.)" non ?

Tout va dépendre de ton utilisation. Il est probable que pour un usage non serveur, la perte ne soit pas réellement perceptible.

Tout simplement parce qu'en IPV6, un bloc d'adresse en /64 correspond à 1 LAN

Je sais bien et je ne remet pas en cause ce que tu dis là. Mais en quoi est-ce que les FAI ne respectent pas "ces normes" ?

ou des verrues ignobles tout ça parce que les FAI ne respectent pas la norme IPV6

Tu peux développer svp ?

Alors un petit spoiler pour ceux qui sont pressés : https://fr.wikipedia.org/wiki/IPv6#Attribution_des_blocs_d'adresses_IPv6