Mes questions à la con - Page 1

Suite à un lock dans le sujet super cadré "J'ai rien à dire mais j'ai envie d'en parler - Les questions à la con", j'ouvre "Mes questions à la con".
Je ne vois pas en quoi ma question rapide était problématique hormis le fait qu'elle contenait le mot linux, mais bref.

---

while true; do dbus-send --session --dest=org.gnome.ScreenSaver --type=method_call /ScreenSaver org.gnome.ScreenSaver.SimulateUserActivity; date; sleep 5s; done a l'air de fonctionner sur un CentOS de test, mais peut-on rendre ça indépendant du bureau ? (là j'ai dû faire une référence explicite à gnome :/)
Par exemple, je suis en train de regarder sur un xfce, et je ne trouve pour l'instant pas d'équivalent dans les services listés par qdbusviewer.

Merci à Zeph pour cette nouvelle fonctionnalité, et aussi pour la récupération des messages lockés, ça roxe

pas moyen d'aller regarder le code de systemd pour aller voir comment ils font?

Mais comme ce n'est toujours pas universellement géré, il y a un script xdg-screensaver dans les xdg-utils.

squalyl ./2 : sans doute, si, mais j'espérais une simple fonction documentée au début

Alors en effet, j'ai testé et ça a l'air de fonctionner (au moins sous CentOS, Java 7) :

import java.awt.Component ;
import java.lang.reflect.Field ;
import java.lang.reflect.Method ;

import javax.swing.JFrame ;

public class W
{
   public static void main( String[] args )
         throws Exception
   {
      JFrame jf= new JFrame() ;
      jf.setBounds(50, 50, 150, 80) ;
      jf.setTitle("Test Window") ;
      jf.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE) ;
      jf.setVisible(true) ;

      //http://elliotth.blogspot.fr/2007/08/transparent-java-windows-on-x11.html
      //long windowId = peer.getWindow() ;
      Long windowId ; {
         Field peerField= Component.class.getDeclaredField("peer") ;
         peerField.setAccessible(true) ;
         Class<?> xWindowPeerClass= Class.forName("sun.awt.X11.XWindowPeer") ;
         Method getWindowMethod= xWindowPeerClass.getMethod("getWindow", new Class[0]) ;
         windowId= ((Long)getWindowMethod.invoke(peerField.get(jf), new Object[0])) ;
      }

      String cmd= "xdg-screensaver suspend 0x"+Long.toHexString(windowId) ;
      System.out.println(cmd) ;
      Runtime.getRuntime().exec(cmd) ;
      System.out.println("0x"+Long.toHexString(windowId)) ;
   }
}

Reste plus qu'à trouver un truc équivalent sous OSX
Merci !

PS : xdg-screensaver status pour connaître l'état du système, et on remarque que tout est rétabli à la fermeture de la fenêtre. On peut aussi (et c'est sans doute une bonne idée ?) faire un xdg-screensaver resume windowId en fermant la fenêtre.

Pen^2: http://stackoverflow.com/questions/5596319/how-to-programmatically-prevent-a-mac-from-going-to-sleep

Mieux: https://developer.apple.com/library/mac/qa/qa1340/_index.html

Par contre ta methode linux va completement pas marcher du tout si la pesonne n'utlise pas xdg-screensaver. (Et crois moi il y en a plein)

Tout le monde n'utilise pas systemD, et ce n'est pas non plus parce que ce truc est installe que tout ces outils sont la, les gens qui utilise des DM autre que KDE ou Gnome on de tres forte chance d'utiliser d'autre outils. Il faut que ton code s'attende a ce que ce script n'existe pas..

( http://stackoverflow.com/questions/460140/is-there-a-decent-way-to-inhibit-screensavers-in-linux <- La premiere reponse est un tres bon resume de la situation)

xdg-screensaver gère tous les environnements de bureau et aussi le bon vieux xscreensaver. systemd n'intervient pas dans ce cas. (En revanche, si on veut aussi bloquer la suspension/hibernation, alors là oui, il faut parler à systemd-logind, c'est une API séparée.)

Il faut que les xdg-utils soient installés, mais ce n'est qu'un paquet de scripts cross-desktop (et au pire on peut les bundler, mais alors on doit les mettre à jour régulièrement parce que des nouveaux environnements apparaissent, des environnements existants changent d'API (par exemple pour passer à org.freedesktop.screensaver, que j'espère tout le monde finira par utiliser) etc.).

Kevin Kofler (./7) :
(En revanche, si on veut aussi bloquer la suspension/hibernation, alors là oui, il faut parler à systemd-logind, c'est une API séparée.)

Ah ?
Pffffff... Bon, je crois que la fonctionnalité ne sera pas dispo sous linux, ça commence à être un peu long pour juste inhiber une mise en veille...
Ou alors je fais bouger la souris discrètement toutes les minutes...
Si l'utilisateur s'en aperçoit j'accuserai les drivers

systemd-inhibit --what=sleep:idle --who=Pen^2 --why="parce que" --mode=block sleep inf
Tu lances la commande quand tu veux commencer le blocage et tu arrêtes (tues) le processus pour arrêter le blocage. (systemd utilise les notifications de D-Bus pour détecter l'arrêt du processus.) Alternativement, tu peux utiliser un wrapper script qui lance ton programme à l'intérieur de systemd-inhibit. (Mon sleep inf est un hack. )

j'adore le --why=tagl parce que ca a l'air d'être une option obligatoire

Ce n'est pas obligatoire, la commande marche aussi sans donner une raison. La raison est affichée dans systemd-inhibit --list.

Quant au --who, c'est normalement le nom du logiciel.

OK merci, cela dit ça n'avait pas l'air d'exister à l'époque de CentOS 5.
Si je pars sur systemd pour les linux modernes, il y a un équivalent pour les plus anciens ? (sinon tant pis, mais c'est quand même dommage de ne pas avoir mis en place une couche d'abstraction long terme)
edit : pas disponible non plus sous ubuntu 10 (enfin, pas dans le path en tout cas)

Logique, CentOS 5 utilise SysVInit (CentOS 6 utilise Upstart, CentOS 7 utilise systemd, les versions à venir utiliseront probablement aussi systemd), Ubuntu 10.mm utilise Upstart (Ubuntu est parmi les dernières distributions à être passé à systemd).

Mmmm OK, merci. Et il y a encore beaucoup d'autres variantes à gérer ?
Sérieusement, les logiciels de lectures de vidéos essaient de gérer tout ça ?

À mon avis, essayer de gérer les systèmes sans systemd dans les nouvelles applications n'a plus aucun intérêt de nos jours, on développe pour le présent et le futur, pas pour le passé. Les distributions sans systemd sont en voie de disparition.

Kevin Kofler (./15) :
Les distributions sans systemd sont en voie de disparition.

La réponse est clairement non.

Gentoo n'est pas en fois de disparition, Funtoo non plus, et plein d'autre distribution Linux et autres *BSD.


Et je finirais avec cette citation:

So the next time you hear people characterizing alternative-init fans as "haters" and "whingers", the question you might want to ask the epithet hurler is this: "What do you have against choice?"

http://www.troubleshooters.com/linux/init/manjaro_experiments.htm

Je signale que la source de ta citation, Manjaro, utilise maintenant un installeur, Calamares, qui présuppose systemd à plusieurs endroits.

Et l'article que tu cites prétend que réinventer la roue au lieu d'utiliser des bibliothèques toutes prêtes rende un logiciel plus maintenable (!) et qu'il ne soit pas normal (en 2014, date de l'article) d'utiliser Qt 5 (sorti en 2012!) et qu'il faille continuer à utiliser Qt 4 (qui a eu sa dernière feature release en 2011, et qui maintenant en 2015 ne reçoit plus aucune mise à jour) même pour les nouveaux logiciels! C'est vraiment n'importe quoi.

Kevin Kofler (./15) :
À mon avis, essayer de gérer les systèmes sans systemd dans les nouvelles applications n'a plus aucun intérêt de nos jours, on développe pour le présent et le futur, pas pour le passé.

Kevin Kofler (./15) :
plus aucun intérêt de nos jours, on développe pour le présent et le futur, pas pour le passé

Kevin Kofler (./15) :
on développe pour le présent et le futur, pas pour le passé

Kevin Kofler (./15) :
pour le présent et le futur, pas pour le passé.

Kevin Kofler (./15) :
pas pour le passé.

Kevin Kofler :
Il y a effectivement 2 problèmes distincts:
1. Le HTML 5, qui rajoute tout un tas de tags que les navigateurs doivent gérer, beaucoup plus que nécessaire (VIDEO et AUDIO, je veux bien, pour compléter IMG* et remplacer la pourriture de EMBED/OBJECT**, mais là aussi, le standard définit des moyens d'avoir des contrôles en JavaScript, ce que la plupart des sites utilisent, alors que ça devrait être au navigateur d'afficher des contrôles adaptés à la plateforme. Tous les autres tags rajoutés dans le HTML 5 ne font que compliquer les navigateurs pour rien.), et qui oblige de facto à utiliser le CSS en déclarant obsolètes les simples tags de formatage comme FONT, B et I (déjà dépréciés à tort dans le HTML 4).2. Le "Web 2.0" (voire "Web 3.0" etc.), qui date déjà d'avant le HTML 5, avec tous ses problèmes: beaucoup trop d'accent mis sur le formatage (cf. CSS) au lieu du contenu, abus de JavaScript pour abuser du web comme plateforme d'applications et/ou pour remplacer carrément le code HTML (statique ou généré dynamiquement sur le serveur) par des générateurs de HTML côté client (beurk! sick Le principe du web a toujours été que le JavaScript doit être optionnel et qu'un site doit fonctionner au maximum possible si un navigateur ne gère pas des fonctionnalités optionnelles ou si elles ont été volontairement désactivées par l'utilisateur!), etc.

On s'est pris la tête tout un topic où tu expliques que le web "moderne" est désespérant comparé au "bon vieux temps".

Et desole, mais une distribution qui n'utilise pas SystemD n'est PAS le passe, surtout quand elle est maintenue. Alternative peut être, mais surement pas le passé.

J'arrete sur le sujet car de toute maniere on sais tres bien que tu ne changera jamais d'avis meme si on te prouvait par A+B que tu as tord.

Allew bon courage.

Ce que je veux dire par "le passé", c'est que ce ne sont pas les versions les plus récentes (de Debian¹, RHEL², CentOS², Ubuntu³ etc.), voire des versions qui ne sont plus maintenues (par exemple dans Fedora⁴). Maintenant, il est vrai que Gentoo conseille toujours OpenRC (mais propose aussi systemd, parce que leur spécialité est bien de tout proposer), mais à part ça, quelle grande distribution n'est pas encore passée à systemd?

¹ Debian installe systemd par défaut depuis Debian 8 jessie (la stable actuelle). [1]
² RHEL et CentOS utilisent systemd (obligatoirement, à moins de configurer tous les services à la main comme l'a fait l'auteur de ton lien) depuis RHEL 7 / CentOS 7. [2]
³ Ubuntu installe systemd par défaut depuis Ubuntu 15.04 Vivid Vervet. [3]
⁴ Fedora utilise systemd (obligatoirement) depuis Fedora 15. [4] Fedora 14 n'est plus maintenue depuis le 9 décembre 2011. [5]

Kevin Kofler (./15) :
À mon avis, essayer de gérer les systèmes sans systemd dans les nouvelles applications n'a plus aucun intérêt de nos jours, on développe pour le présent et le futur, pas pour le passé. Les distributions sans système sont en voie de disparition.

Quand on n'a pas beaucoup de moyens ou autre chose à faire que passer son temps à faire du packaging, c'est clairement la bonne solution. Ça permet de viser une bonne partie du parc Linux à faible coût.

flanker (./22) :

Kevin Kofler (./15) :
À mon avis, essayer de gérer les systèmes sans systemd dans les nouvelles applications n'a plus aucun intérêt de nos jours, on développe pour le présent et le futur, pas pour le passé. Les distributions sans système sont en voie de disparition.

Euh non, je n'ai pas fait ce lapsus: une distribution sans système, ça doit être un peu dur à faire.

désolé, correction automatique qui a fait du zèle ^^

Bon OK, merci, ce sera donc du systemd.