From mint-bounce@lists.fishpool.fi Sun Jan 31 13:50:52 2010 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=seznam.cz; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer:X-Smtpd:X-Seznam-User:X-QM-Mark; b=KR6xaQahDjWmSHnbmZa9mvLASgn3ZNsidQE4g2veWKWp0QTlvyWVi5PR1ohdIhT+i y0LsLI0hIbQ+BrmePxtmX+KqcLxrnYGz+IYDY63NPOGbY76sRKX56TxRdVXbZH1SO1B x8NDxNhQmwSx9vvVWknzffB6v27ISZkdko3TK+0= Cc: mint Message-Id: <231FB8B6-8A4A-4EE1-A09B-33C8D77817DC@seznam.cz> From: Standa Opichal To: Paul Wratt In-Reply-To: <11a6f2b11001302144r453c353xdb21efddf53b2ee4@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [MiNT] mono (was: Re: QED) Date: Sun, 31 Jan 2010 19:48:39 +0100 References: <11a6f2b11001270642j41b73ecepfd4a7a7cbb3fb354@mail.gmail.com> <11a6f2b11001302144r453c353xdb21efddf53b2ee4@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-Smtpd: 1.1.7@13984 X-Seznam-User: opichals@seznam.cz X-QM-Mark: email-qm3<291503846> X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: opichals@seznam.cz Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Hi Paul! I know it is probably not the thing what most people here would want to hear but IMO it would be less time consuming to port FreeMiNT/TOS APIs, VDI and AES on top of the current NetBSD/FreeBSD codebase then trying to implement the necessary functionality into the FreeMiNT kernel itself. We could nicely call it e.g. Mint(Free|Net)BSD! :) There you get all the apps bundled.... m68k specific patches could still be applied from their SpareMiNT RPMs. And you might even get cross-compile capable packaging system. But that's probably way off the discussion here. I am just trying to put man-years quote on the work to be done to reach the goal... Standa On Jan 31, 2010, at 6:44 AM, Paul Wratt wrote: > On Wed, Jan 27, 2010 at 2:19 PM, Standa Opichal > wrote: >> Hi Paul! >> >> WRT mono... tried to port it on several occasions and then gave up. >> Got to >> the point the mono CLI >> was dissasm working. But not the interpreter, not talking about the >> JIT >> itself. Two basic common >> things missing in our kernel for easy ports: virtual memory (and >> the libc >> mmap()) and threading (pthreads). >> > Thanks for the update, MONO is a large effort > > Yeah, these seem to be recurring issues, even for non-port > development, it is really an essentual parts of modern OS, an VM would > allow a lot of older machines to run more software. > > Pthreads is another "kettle of fish", and may require complete > redo/overhaul of multitasking parts of kernel. This is a tough one > because there are not many people who can do such things even outside > of ST/mint development. > > One way I have proposed to tackle these issue related to porting at > least, is to use dummy or replacement libraries, so the functions used > in code dont need to change, and the lib supports what it can, and > does other things where the OS cant handle it. > > Its not a perfect fix, and something like pthreads would probably just > be easier to add the missing parts to kernel to get the correct > support. > >> Somebody should provide these for FreeMiNT on the CF machine (and >> perhaps on >> 040/060) or you >> risk porting modern packages will always be great pain + rarely >> ever a >> possibility for upstream >> acceptance. >> >> Standa > > There are a lot of people around atm, and I expect at least for the > next 12 months. Something will happen here I have no doubt. It might > get done quicker if peeps knew what was needed, and could supply > chucks to get the project(s) completed faster, as opposed to relying > on one person, or team. > > One thing I have noticed about Atari ST/Mint development (atm), is > that most people either have family (kids), school or job, which means > they dont have a lot of time to dedicate to projects. However, if they > could spend a few hours here and there supplying pieces, then even a > relatively large project could be achieved. > > There are a few like me who do have the time to put into documenting > what is needed and where (and doing other boring stuff). I am > constantly on the look out for things that can fill or help fill a > need in Atari ST/Mint development, especially source code, and have a > large collection atm. > > If I can collect such things as you have done with mono, document what > is needed, and where, which is part of providing cross-referenced docs > and dev docs, then others can take a look at specific things as time > allows, instead of "re-inventing the wheel" or ending up with another > dead project. > > I, to do these things, and others, to find, discuss and provide these > things, need to have an infrastructure which can support these types > of initiatives. The beginning of which is a useful wiki. > > The other thing I note about ST/mint development, is that one person > often takes on the job of providing something, but as pointed out > above, they do not have the time to commit 100% to getting it > completed ASAP. > > In this case (bare with me here people), the wiki is a good example. > Yes content structure and clarity are required. But if only one person > is allowed to provide the content, then what is the point of using > wiki in the first place. In this example, everything that was needed > could have been added within a week by many people, and the person > taking responsibility for it could have re-organised everything, once > a layout was decide, others could then have assisted in the > restructuring. > > In this case also, wiki is less about structure, and more about > structure evolution. There is only ever a small set of key things > needed documentation wise (for any project), everything else is an > added bonus, and evolves as needed or as time permits. > > So, with that in mind, I hope to start providing these currently > missing access points for projects, documentation, help docs, dev > environments, required downloads, or quickstart guide, in such a way > as others can both use and edit/add as there time permits.. > > ATM it is differcult to provide the required integration simply > because I believe it should not reside on my servers. The majority of > information is physically available on one server, and to that should > be added more dead and abandoned projects (like mono mentioned here) > that have relevance. This should extend to at least a minimum set of > full apps and libraries that allow full OS usage and/or development > (including porting) > > However the management of all of this needs a user system like wiki, > which does not need any human response or confirmation in order to > sign up and contribute, and yet keeps history and makes branching > possible (for dev work), without the need for setup from any one > individual who may otherwise be unavailable for whatever reason. > > OK, nuff for the moment, every minute spent replying to mailing lists > eats into the time I need to provide the above. To anyone associated > with comments made in this, please do not take offense, it was not > meant in that way, and is unproductive, which is counter to the > essence of this post, working solutions are always better > > If anyone else has dead projects (I already know about the abandoned > projects on the ICQ site) or has incentive to provide written material > (ala http://wikipendium.free.fr/) please speak up, there are a ton of > areas to contribute too, many of which are not boring :) > > Paul > >