Sander van Rossen wrote: > Congrats with your brother ;) Brothers, thanks. > SharpWS stands for Sharp Windows System, it will be a while before > it'll be even close to operational tough... we don't even have > graphics in SharpOS... > ... at least: not yet :) Sweet. Yesterday I was looking to how graphics drivers work in Linux, but don't except nothing good from me... It's the best source (only) for this nfo. It's at times like this when I realize how important the opensourceness is, especially for an OS. A best bet for us is to start with a simple VGA driver and VESA later, then think of the system graphic library... ...Should we port MESA? If so then should we count on GCC-CIL? I'm somehow worried if it would be reliable enough in both performance and functionality for this task... ...Or should we start our own graphics library in C#? It's a BIG engagement! But we like challenges. Don't we? ;) If so, shall we design it so that it stands for GDI+/cairo, pango and OpenGL all in one? IMHO it should be one big library. Well modularized of course, but perfectly integrated too. So we could write our widget system in OGL-like environment with support for hardware graphics, and vice-versa insert widgets, unicode text and stuff easily into multimedia applications. Oh and for media streaming, do you prefer gstreamer or phonon like solution? JK... Actually, we'll end up with a similar topic someday, probably :P
> Since i won't be able to attend the meeting, i'll just throw my 2cts > in beforehand on some of the topics. > > > About the whole "GC: use one GC for all SIPs (software-isolated > processes) or one GC per SIP? " thing.. I just happened to see one of Singularity publications, here's a piece of it: <<Unlike Singularity’s segregation of SIPs on disjoint memory pages, other safe language systems have taken the approach of having processes allocate memory from a single, shared heap. Singularity’s design has several advantages. First, it reduces coupling between processes by eliminating the shared memory allocator and garbage collector and by permitting each process to allocate and reclaim its own memory using the techniques that are appropriate. The large number of existing garbage collection algorithms, and experience, suggest that no one garbage collector is appropriate for all systems or applications, so this flexibility helps achieve good system performance [17]. A shared heap and garbage collector constrain the object format and run-time system of every process that uses it. Moreover, these shared facilities are a common point of failure. Second, Singularity’s design facilitates process termination, as the system can simply reclaim entire memory pages, rather than relying on garbage collection to reclaim individual objects.>> As for the last one note also "Singularity’s segregation of SIPs on disjoint memory pages". On the other side, shared GC could be better for small devices. I think they support both though, but I'm not sure. Correct me if I'm wrong. What do you guys think of Singularity's ways of things: SIPs, channels? I'm not well conscious on all this stuff... ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers
