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. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
