On Tue, Dec 18, 2012 at 5:12 PM, Maxime Villard <rusty...@gmx.fr> wrote: > Le 18/12/2012 00:15, Vincent Torri a écrit : >> 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 >> 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. >> >> Vincent > > > As far as I'm concerned, I already sent a lot of patches to support > BSD's. > > I'm busy the week, but free the week-end. The w-e, I send patches and > I have to wait, wait, wait, ... and to resend a mail two weeks later > only to know if someone gives a fuck; and then I have to convince the > person who cares - if there is one - to commit that patch, which at > last gets committed if another one is not needed because of a change > in the concerned file during these 2 weeks. > > Now there is still no full BSD support, and e will probably released > without it. Seriously ?
it depends : e17 does not depend on efl trunk, but on efl 1.7 that are in branches/. So if e17 workds with those EFL, then there will be no problem 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
