On Tue, 18 Dec 2012 00:15:25 +0100 Vincent Torri <vincent.to...@gmail.com> said:
> On Mon, Dec 17, 2012 at 5:14 PM, Maxime Villard <rusty...@gmx.fr> wrote: > > Le 17/12/2012 01:10, Carsten Haitzler (The Rasterman) a écrit : > >> the reasons are many but here are some: > >> > >> 1. devs are almost all on linux... so guess what? they support the os they > >> work on. > >> 2. frankly linux has much more momentum than the bsd's (excluding osx as > >> you say) and that lead as i see is only increasing. > >> 3. the only other really "relevant" platforms are probably osx and > >> windows. both of these can be dealt with. yes i know about psl1ght and > >> many other more niche users. evil is there to fill in gaps for windows. it > >> can provide shm _open by opening a file on disk and mmaping it like it > >> already does. if there is an ability to force a file in windows to never > >> be flushed to disk unless memory pressure would force it to be swapped out > >> to the pagefile - then this is effectively the same behaviour... except it > >> survivies a reboot. for osx - if there is a tmpfs that lives in ram, an > >> shm_open can be provided that redirects to there. i don't know if there is > >> - no osx. > >> 4. for decades linux users have been at the bad end of the stick with > >> people simply saying "well be posix compliant! make your own drivers" we > >> won't support you!"... the tables are turning. slowly - in bits and > >> pieces. and most linux users/devs are of the mindset of "we had to support > >> oursevles for years... and so we did. time you did the same". :) > >> > >> the issues on the most part can be solved. the problem is that for the vast > >> number of the core devs.. it's not THEIR issue (with some exceptions - yes > >> vincent... :) i know :)). ecore-extn was optionally compileable before > >> because i know it uses shm_open and so i made it an option. it also > >> brought in ecore-con and ecore-ipc. these options are going away now > >> though, so the problem is no longer going to be avoided. cserve2 - similar > >> story. we've had cserve for years now and no one uses it - it was > >> optional. cserve2 will become mandatory because it NEEDS to be tested and > >> exercised en-masse. without something like cserve2 - we will bloat out > >> badly if people write actual efl APPS. cserve2 is there to help contain > >> that bloat before it begins. people are already writing efl apps, so it > >> solves and existing problem anyway. the issues just need solving. in both > >> the eore-extn code and in cserve2, the shm_open/mmap stuff is encapsulated > >> and easy to replace etc. - it just has not been because of the above. the > >> devs all have systems that have shm_open... so its not a priority for us > >> and your todo lists are forever full. example. there is a case with > >> ecore-extn where u can easly get a lock deadlock if you use it in a > >> certain way. reality is people do use it that way and that problem is by > >> far more important to me than shm_open stuff. :) > > > > So, excepted me, nobody uses and feels concerned by BSD's ? > > they don't care about other OSs. They work exclusively on linux and > don't even try to think about other OSs. It implies that a port for that's total bullshit. utterly. we think. we simply make decisions that doing development and improving efl - using api's specified in posix for a long time now is more important than STAGNATING and NOT doing development. i listed by sysvshm is far worse than shm_open already. i spent time actually reading up on these (apparently unlike you). we cant (portably - except with extensions.. only on linux .. resize sysvshm segments. shm_open can be easily implemented "dumbly" just with tmp files, but you lose the benefits of an explicit shm_open that says "hey - this is not really meant to be a file... it's shared memory - so many u dont want to allocate real disk nodes/blocks and sync any data to disk (unless you have to swap - then put it in swap as usual)"... i started using shm_open because it solves the "crap sysvshm" problem AND sets the right "hints to the os" for the shm file. > another OS than linux has to implement very bad hacks and a ton of > work, like i did for Windows, to try to *mimic* what is done with > linux. correct. like linux had to spend decades implementing hacks to mimic solaris, and ultrix and aix, and irix etc... now the tables turned. > Vincent > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
