On Thu, 27 Oct 2016 10:39:47 +1030 Simon Lees <sfl...@suse.de> said: > > > On 10/27/2016 04:58 AM, Cedric BAIL wrote: > > On Tue, Oct 25, 2016 at 5:17 PM, Carsten Haitzler <ras...@rasterman.com> > > wrote: > >> On Tue, 25 Oct 2016 14:32:29 -0700 Cedric BAIL <cedric.b...@free.fr> said: > >>> On Mon, Oct 24, 2016 at 10:31 PM, Carsten Haitzler <ras...@rasterman.com> > >>> wrote: > >>>> On Fri, 21 Oct 2016 15:14:20 -0700 Cedric BAIL <cedric.b...@free.fr> > >>>> said: i've been mulling this. i followed the feedback so far. basically > >>>> 2 main things: > >>>> > >>>> 1. this is intended to improve performance. especially startup times. > >>>> 2. this is highly problematic in terms of portability and is going to > >>>> create lots of code and build paths. > >>> > >>> It won't create lots of code and build paths. In fact it doesn't even > >>> need two build paths. It just needs to uses all .la files for building > >>> quicklaunch and can be rolled in, in parallel to current system. Just > >>> the link of the quicklaunch binary would be different. Next step would > >>> be to make a build option that setup symlink to that binary. Finally > >>> that option would be the default, likely only afffecting the install > >>> process. I don't think that create a lots of code (There should be no > >>> code change) and build paths change at all. > >> > >> why are you doing a symlink if its JUST a quicklaunch binary change (that > >> statically compiles all of efl into it)? > > > > As said it is a multiple stage update path. First just a change to > > quicklaunch, which should work by itself. Then we can switch from real > > libevas.so.1 to a symlink to that binary. This allow us a progressive > > try without breaking everyone right away and making it possible for > > people/packager on other OS to try it first. > > > >> you are trying to replace all of libevas.so.1, libeina.so.1, etc. with > >> symlinks TO this quicklaunch binary ... to retain binary compatibility. > >> you cant have the .so's AND this ql binary both have the same set of > >> symbols. asking for trouble there. > > > > It shouldn't be a problem thanks to DSO on most system. System without > > DSO may be an issue. > > > >> but to USe this binaries HAVE to be PIe and this makes for a non-portable > >> pain in the arse of creating apps. which is why i did .so's for > >> quicklaunch before.. because it also works with dll's on windows. PIE does > >> not. not that i could find. > > > > Most system have some form of PIE due to the need to implement ALSR. > > For windows, let follow up the discussion with Vincent. > > > >>>> 3. this makes debugging and other things a nightmare (ps names are all > >>>> the same .. well depending on tool etc.) > >>> > >>> This is exagerated. Again just need to pass the right command line to > >>> ps/top and problem is solved. Can easily be documented and we can also > >>> provide a script that does it until we provide some nicer application > >>> there. > >> > >> i mean simple user debugging. someone runs ps or top and all they see is 20 > >> processes called "quicklaunch". because depending on the ps tool it may > >> use one proc field or another. so a user goes "quicklaunch process is > >> using N% cpu or N % ram". what real process is that? they don't know. > >> because procps tools will not do what you want and thus the average person > >> will become confused and find anything using efl like this to be horribly > >> hard to work with. > >> > >> if top, htop, ps, killall, etc. don't work out of the box, it isby everyone > >> (except yours) definition... a nightmare. i've messed with this before and > >> it does not work across all the tools because of where they source command > >> (and that can change based on config and cmdline options too). > > > > As said, this is just a matter of alias to be documented. I don't > > think it is so much of a big deal. > > > > As someone who helps with support a lot if top, htop, ps, killall and " > systemctl status user.slice" don't provide correct info out of the box > i'd consider it a deal breaker and broken and would probably look for > ways to patch around it at a distro level.
bingo. thus why i dont think we could at all do a quicklaunch/zygote thing out of the box for everyone. i also see this as a deal breaker. if CURRENTLY 90%+ of ps/top/killall like tools used the same field AND thus showed the right cmd then ok - its a few that use a different field. this is NOT the case right now. it wont be unless these tools change. lots of them. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
