Once we use git, it is easy to move again. On Thu, Dec 3, 2015, 21:10 Gregory Casamento <[email protected]> wrote:
> On Thu, Dec 3, 2015 at 4:00 PM, Luboš Doležel <[email protected]> wrote: > > On 12/03/2015 08:22 PM, Maxthon Chan wrote: > >> On their side, I’m gonna go there and propose the option of using an > >> existing Foundation reimplementation in place of the version they > >> packed. > > > > Over the time that I've been analyzing OS X, how things work deep down, > > I came to the conclusion that developers at Apple must be *really* very > > bored. > > > > While on Linux, one can see the developers are lazy, strive for a clean > > and simple design, Apple's developers probably dream about what crazy > > complicated project of reimplementing something that has already been > > done to start next. > > > > A nice example are workqueues as used by GCD (libdispatch). They > > implemented on top of a portable pthread pool. Then they thought, hey, > > why don't we save us making maybe 1 system call, get the kernel > > needlessly involved in managing the thread pool and feel absolutely > > fantastic about it. > > > > Another example. Pthread locking primitives. On Linux, there is a single > > simple system call named futex. All the mutexes, conditions, r/w locks > > etc. are built on top of that. > > In Apple, they thought this would be way too simple. So instead, they > > introduced a dozen of system calls (psynch_*) with gazillions of > > parameters and very strange semantics. When I read through the > > implementation in XNU, I wonder why did someone torture himself so much. > > > > So when I see Apple redoing something, I'm just not surprised anymore. > > These folks don't want easy and simple. Because then they would have > > nothing to do and would get fired. > > > >> On our side, maybe it is time to scrap our CoreBase and reimplement > >> Base on top Apple’s CoreFoundation. > > > > a) That's a lot of work someone would have to do. And to little benefit, > > I'm afraid. > > b) Makes you depend on APSL'd code. > > Indeed > > > I'd rather suggest that GNUstep finally moves to Git so that I can > > contribute back more easily. Right now, it's easier for me to commit > > into my own gnustep-corebase fork on GitHub then to commit into SVN, > > wait for it to bubble to the Git mirror and merge it into the Darling > fork. > > In process. I am waiting on the guys on savannah to create the > relevant repos. One issue which already comes to mind is that in > order to have multiple repos I have had to make a special request on > Savannah and it has taken them a week to respond to the first one. > > I believe we may want to review our ideas about moving to savannah > because of this. On github or even when I use gitlab (on my own > server) it allows me to just add repos when I need them. > > > -- > > Luboš Doležel > > > > _______________________________________________ > > Discuss-gnustep mailing list > > [email protected] > > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > > > GC > -- > Gregory Casamento > GNUstep Lead Developer / OLC, Principal Consultant > http://www.gnustep.org - http://heronsperch.blogspot.com > http://ind.ie/phoenix/ > > _______________________________________________ > Discuss-gnustep mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnustep >
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
