On Tue, Dec 18, 2012 at 12:50 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > 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
and the port of the EFL on Windows has not starting last year... Since you guys know that there is a Windows port, you have never asked me if a new feature will be problematic or not, except for around one year. I can give several examples... And that's not bullshit. Vincent > 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
