Oh right, let's just dump all the progress we've already got and start completely from scratch. Forgive me if I'm not a big fan of this idea. And now on to your specific points-- you asked for bluntness and you *got it*. But before you read my agitated responses (after all I thought this was a discussion about SIngularity source-- not about remerging the projects), I'm gonna outline a bit about how *I* think we should work this out.
First things first, someone has to give on licensing and I can say for myself at least that I'm not gonna work on a non-copyleft project. You say that the copyleft is not needed because 90% of the time companies contribute back their code regardless of legal necessity but I am not worried about the 90%-- I'm worried about the 10%, and I'm worried about the 100% of the contributors who will get ripped off in those cases. Secondly I'm not going to participate in a project where only a select group of people are able to build, use, and/or contribute to it. This applies directly to the situation Cosmos has where the latest VS and .NET Framework are required and Linux developers are totally out of luck (and it has nothing to do with Mono and everything to do with build environments/scripts, Windows-only tools, Windows-only virtual machine formats, etc etc). Now provided we came to agree on some sort of copyleft license, we would need to merge our codebases, taking the best of breed components. This can't just be up and decided because none of us know all the benefits of each codebase. The only thing that is doable here is a conference of sorts to contrast and compare our differeing solutions for things like the compiler, low level kernel intrinsics, the Runtime implementation, Type metadata traversal implementaiton, GC, corlib, etc. all up the stack. In the case of Ensemble, Scott would need to be willing to make compromises on his design but from what I've got he is more interested in implementing his design so I don't exactly see how Ensemble is even a part of this picture. On to your words... On Wed, Mar 5, 2008 at 3:40 AM, Jonathan Dickinson <[EMAIL PROTECTED]> wrote: > I am going to be as blunt as possible here. I am sorry if I step on toes, > but some harsh things need to be said. Please contend/add comments - this is > my POV after working on all three projects. Be as blunt as possible. Ahhhm, if your email was harsh then mine might break your heart. > Cosmos > Cosmos has it's strengths, firstly it does not adhere to the classical > <Foo>OS or Sharp<Foo> naming paradigms (sorry SharpOS). The compiler is a > work-of-art is very understandable: but does not use IR (Chad, no matter > what you say, IR is needed). It uses the permissive BSD license. Naming is absolutely superficial and the ONLY reason SharpOS is called SharpOS is because we are not interesting in wasting time on some stupid marketing crap. We'll give the OS a proper name when it's ready. Therefore, I think the fact that you consider Cosmos a cool name is not important. And you asked for bluntness-- the only compiler engine out of the three projects which is even *close* to a work of art is SharpOS.AOT. There, I said it. I'm sure Ensemble's will be beautiful because Scott has a top to bottom plan for it-- but it doesn't exist yet. We'll see when it's arrived. > However, as stated, it does not use IR. Furthermore, it blocks out Linux > users. Time for all to grow up and accept that we live in a heterogeneous > environment. Linux/Windows disputes will fall away when we are compiling in > the CIL OS: so let's get rid of them now. Your right here. Shame on Cosmos for locking out a group of contributors because of their platform of choice. > Cosmos stands as a beacon, it shows that a solid runtime makes things easier > in the long run (they have ATA and Ext2 for crying out loud!). Jon, wake up the coffee's brewing. ATA and Ext2 have absolutely nothing to do with a runtime!! Besides, we've got Ext2 code too, but there have been two things stopping it: our broken floppy controller and a filesystem interface (both now being worked on by tgiphil) > SharpOS Mhm. > SharpOS is the original and has had a lot of progress. However, it had a bad > start (which it has made up for now). A solid runtime is needed before > anyone implements PCI etc. We all know it is easy to get distracted, but > focus is needed. A "bad start"? Are you referring to the usage of the low level C# functionality? The functionality which needs to be just as thoroughly tested as the upper level object orientation features? The fact is, doing it the way we did it means that our low level facilities are just that much more tested than il2cpu could even imagine. We've got airtight low level support, and we have proven beyond any doubt that our compiler can take low level code. And now we're doing the same with the upper level features, taking it at the same speed we did with the low level features. This is NOT something which should be (or needs to be) rushed, unless your ready to just hack together a string of hacks so that you can pretend like your OS will continue standing after you've changed a single semantic you didn't plan for. > GPL if we must, but fewer people have problems with BSD. It is naive and insulting to make some kind of comparison between the popularity of the BSD and GPL licenses. Things like that are just not true. As I see it, there seems to be quite an equal distaste for the other's licensing. Besides, our small sample is certainly not a good estimate of the realistic popularity of the two licenses. As for the commercial crap, it's just so goddamn strange that commercial entities would endorse BSD which skips the link from completely closed to completely open. Then again, Trolltech is a good example for the case where a company releases it's OWN code under an open source license: they chose GPL--- so that Trolltech Qt won't become the patent-pending Wondersoft(R) Cutekit(TM) released under a EULA in a couple of years. > Cecil is a wonderful thing. But this is not it's place: it does a lot of > automatic inference that really slows things down (Cosmos saw a roughly 2x > speed increase after switching to a custom IL Reader). You might be right but I'm EXTREMELY curious to hear some numbers from the il2cpu camp on how fast their compiler is, because right now the SharpOS kernel compiles in less than 7 seconds on my box, using a tiny fraction of RAM--- I'm on a 1.7ghz celeron box with 512MB ram and a slow hard drive. So there. Please. Grace me with the numbers. Is getting rid of Cecil really the only way you guys could speed it up because it must be BLAZING fast. It only took one guy on our team something like 2 days of profiling work to make our AOT orders of magnitude faster, to the point now where it's already done before I realize it's running. > SharpOS has a lot of code that was made before a solid runtime was > supported: which needs to be re-written for the new features. Hardly rewritten but refactored. For instance I wrote the system clock code originally using the low level facilities. When the object support was far enough along I ported it to use objects. It took me all of 2 hours to get it ported. Ha. Why isn't more of SharpOS like that now? We have a kernel rehash coming up once the new features are more stable but for now we've got LOTS of stuff to implement. If you've been tracking our progress (oh come on you know you want to)... we've got everything short of GC and a full corlib, the latest addition being generics. > Serious thought needs to be given about just linking in the Mono BCL/FCL. Your right on this but only partially. I think that large portions of the Mono CORLIB (please, stop calling it a BCL or FCL and just call it what it is) can be merged in alongside our Korlib code, but I think that it will need to be in a much less foggy way (right now we are looking at importing a set of types and it's dependencies, whereas we should really be going only for the set of explicit types, and reimplement what is not included). But using Mono's corlib still has a *lot* of merit and has proven to be an excellent way to rigorously expose the bugs in our high level facilities. > Ensemble > Not much to say here, but the project is in its infancy. Built from the > ground-up to support JIT etc. Ensemble's problem is it's rigid focus on an untested design. This comes from Scott's desire to see his design put together but NEITHER of you know if the design is going to work or not. Scott, Chriss and I had a very long discussion where Scott described some of the differences and we proceeded to nail off long lists of where he's probably going to have to compromise between his design and creating a feasible system. > New Entity > Let's collaborate on: > > 1. A name Names don't matter. Never did. Look at Linux. At first glance you might say "Hey, that's very original why would you say that?" Well no. It's not. Linux is Linus's UNIX which makes the name about as creative as SharpOS if you think about it. > 2. A license (let's not just use the shotgun rule with GPL or BSD, maybe > a new license even) "Shotgun" rule? We have hashed out many times compromises on licensing but there are always some stakeholders who won't go for it. > 3. A SCM solution (SVN seems to work very well, but other better ones are > popping up - e.g. Mercurial) Hrmmm. The last project that I was involved in that used a more deviant SCM was called Xouvert. It was a fork of XFree86 which came before Xorg. It did not have the X titans (like Xorg did) which it needed but there was still a lot of interest. The leaders chose Arch for SVM which is about as far from CVS as you can possibly get. The result? Few participants, general disinterest in learning yet another SCM. Why is Subversion so goddamn popular? Because it's like CVS make no mistake. It's basically just a (far) saner version of CVS and because of that developers don't have to change their entire paradigm. I think that's a good thing. We aren't here to experiment with different ways of merging changesets we are here to write an operating system. Subversion suites our needs perfectly. > Name > > * SCE (SharpOS Cosmos Ensemble)? In the true spirit of conglomerations. > * Unity? That is what it is. Ehm, SCE == Sony Computer Entertainment? But like I said, naming is the VERY LEAST of our concerns, yet it tops your list here. > License > > * GPLv3 with Classpath Linking Exceptions > * New BSD These can't possibly be considered suggestions? We've hashed through them innumerous times and never found a way to convince either side. > * Something new > o Statement of no liability > o Original copyright message to be included in all > derivatives/compilations > o Any in-band improvements must be made against the original > trunk > + So that we don't loose out to ISVs > + So that ISVs can still use our code (but we reap the > benefits). We are not lawyers and I am hoping that I won't have to hire one for SharpOS at all in the near future (except for maybe getting that non-profit Foundation set up oooo) > SCM > * SVN > * Mercurial SVN. It's the way to be, honestly. Mercurial, Arch, Git, all these things are beautiful ways of moving bits around but they are just too different. We'd end up losing participation just because of the build system, I've seen it many times. In closing, yeah peace would be a good thing for all of us and yeah we are duplicating effort, and yeah starting from scratch is by far the worst way to do it. From my perspective, SharpOS has not been hurt by the existence of the other two projects... we've only continued to grow. But from what I can see, it is most definitely affecting the livelihood of the other two projects, neither of which seem to be exactly "thriving". I hate to bring it down to this fact but it's there. We're doing *just fine*, so why should we have to compromise on our beliefs for so little benefit? -- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers
