On Thu, 26 Mar 2020 15:22:45 -0400 Daryl Kuchay via enlightenment-users <enlightenment-users@lists.sourceforge.net> said:
you need to split efl and e. e uses systemd if its there. specifically it uses logind.it uses it via dbus to do things like suspend/resume/reboot/halt etc. just by sending a dbus request (and listeiing to systemd when it says you have resumed). without this it has to use a setuid root shim to run commands to do this instead and that is there. you may have to customize the config as to what commands to run as this never really was standardized. systemd+logind stanardized it. e doesn't know when you resume. there is no real good way to know. it does try guess to see if it gets acpid input and checks timestam;ps and if it sees a huge jump in the walltime clock after it requested to suspend then it guesses this might be a resume... but systemd just stnandardizes this to a simple dbus message to listen to. but far more importantly .. moving to be a wayland compositor needs systemd/logind even more. without this there is no way to get input device file descriptors or manage access to them securely. systemd/logind handle opening of the input device fd's when asked and it fd-passes them over sockets to e so e now can get input from kbd/mouse. without this only root can. but importantly... systemd/logind are involved in vt switching. so you switch vt's away and it revokes aces to those fd's. that means the immediately stop working in e. if you run another compositor as another user - they also do the same thing - ask for input fd's. as u vt switch,the fd's will get revoked and the newly active compositor will go request the fd's again since its old ones were revoked. this means you can have 2 users logged in on different vt's, switch back and forth but one cant keylog the other in the background. we rely on systemd+logind for this. there is elogind - i don't test it. you are on your own there. but this standardization is really important. it provides a simple standard, consistency and security. we have god reasons to require this. without this no wayland compositor for you. now this support is done mostly in efl in elput (the input abstraction lib for running in a vt). in addition in efl (ecore) we have systemd modules that do things like procue events for e and elf apps when things like hostname change (since systemd provides such events for us - again - standards). also when time/date change - it provides events we then feed into the efl app ()e inclueed) loops. locale change events. you can build efl without this: -Dsystemd=false. also in e too. so you can build without. that's how efl and e work on freebsd. but then you give up some standards and features too. you give up functionality and are now working on code paths i do not test regularly and all day. they may have bugs in them as they are just rarely used. because you ax a user have chosen to not support simplification of development for devs via standards, then it kind of makes us devs get fairly unhappy about you making our lives harder. we have enough work to do to support lots of distros and os's. when something tries to bring things together and standardize it's a good thing, but if users insist we do not that is relatively irritating as it basically is them forcing "do not improve or change" on us. so that's why i take a "well ok -you do not wish to change - go disable systemd support and you test it and fix it when it goes wrong... since it was your choice... :)" so my answer really is - we use systemd because it brings value. it brings standards. it brings more simplicity and for things like being a wayland compositor .. it makes it possible at all. since most distros now use systemd and most users have it... it's the vast majority and thus what is going to be tested and well supported. it's not some religious argument or philosophy. it's just practical "it makes things better or possible at all", and this is from developers who directly interface with it and would otherwise not have solutions or have tow rite 2, 3 or 4 or more kinds of solutions for different distros and then deal with the testing and debugging of those. there is a path to avoid systemd.... but caveats apply as above. :) > Greetings, > > Various linux distributions support your project. Some more than others. I > became attracted to E when Carsten first announced DR17 years ago. Been > interesting watching it change over the years. I want to use EFL and went > towards gentoo. Partly due to being in america and having the time to install > it. But mostly because I like the idea of a source based distribution. That > and I wish to avoid systemd. > > This being said I see systemd as a requirement for Enlightenment. When did > this happen? Slackware for one does not have systemd but they only have a few > packages if you look in to slackENLIGHTENMENT. Is this a direct correlation? > Meaning does not using systemd cause less support from being abe to install > all the applications? > > I am most attracted to Gentoo because a github user looks to have entrance > working again. May I ask why the developers of E started to insist upon > systemd? I absolutely love your software but may take a few days to think > about options if systemd is absolute from your end. I had hopes of learning > and using efl for some neat projects going forward. Is it possible to learn > how to develop on efl on say mac osx? Im sorry if my opinion is not respected > however I got in to linux for hating microsoft after they sued my school > almost out of existence. Comparisons aside I am not sue I want to use systemd > and I will make a decision based on replies. > > > Thank you in advance > > Daryl > > > > _______________________________________________ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
