From: Eric S. R. <es...@sn...> - 2000-03-07 22:39:31
|
I have uploaded a draft web page and project description. About the only thing there that might be even mildly controversial is the list of deliverables. Anybody got a problem with these? -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> "If I must write the truth, I am disposed to avoid every assembly of bishops; for of no synod have I seen a profitable end, but rather an addition to than a diminution of evils; for the love of strife and the thirst for superiority are beyond the power of words to express." -- Father Gregory Nazianzen, 381 AD |
From: James S. <jsi...@ac...> - 2000-03-08 00:15:54
|
On Tue, 7 Mar 2000, Eric S. Raymond wrote: > I have uploaded a draft web page and project description. > > About the only thing there that might be even mildly controversial > is the list of deliverables. Anybody got a problem with these? Looks good. Something nice is maybe add is previous and present approaches to a new console system such as Vojtech work (http://www.suse.cz/development/input), Evstack (look in archive) and probably other solutions that will come out of the woodwork. What are/where the basic ideas behind them. What problems they had/have. Then we can explain our approach. How we are attempted to solve these problems they are/have encountered. As we figure out what we are going to do we can write a long term page since the things on the page right now could go in with the current 2.3.X kernels. "Look its a text editor, not its a OS, no it Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
From: Eric S. R. <es...@th...> - 2000-03-08 00:52:58
|
James Simmons <jsi...@ac...>: > Looks good. Something nice is maybe add is previous and present > approaches to a new console system such as Vojtech work > (http://www.suse.cz/development/input), I'll add a pointer to the "Related Resources" section. > Evstack (look in archive) The EvStack site at pepsi.visus.com has apparently disappeared. > and > probably other solutions that will come out of the woodwork. What > are/where the basic ideas behind them. What problems they had/have. Then > we can explain our approach. How we are attempted to solve these problems > they are/have encountered. I'm not qualified to write these explanations. If somebody on the list is, rough up something (plain text is OK) and I'll webify it. > As we figure out what we are going to do we can write a long term page > since the things on the page right now could go in with the current 2.3.X > kernels. Well...deliverables 1 and 2 maybe. Hm. We need names for these. I dub them "Sapphire" (2.2.x emulation patch) and "Emerald" (2.3.x emulation patch). The more advanced stuff in deliverable 3 ("Ruby") really is new features and will probably have to wait for 2.5.x if I know Linus. I think we need to first develop a modest, easily comprehensible set of Sapphire and Emerald patches that bug-fix the emulation, without trying to hit the larger issues yet. By doing this, and getting these patches accepted, we'll open the door for more ambitious things later. I'm working on Sapphire right now. I've downloaded Dominik's 2.2.1 patch and am reconciling it with 2.2.12. My objective is to produce a minimal patch that doesn't include a whole bunch of formatting changes. I'll test that patch on my stock Red Hat 6.1 system. Once I have that verified, I'll generate a patch for console_codes(4) that updates it appropriately. Dominik, you could speed things up by sending me a functional description of your changes. Next step after that would be to generate a minimal Emerald patch, test it, and check that the updated console_code(4) page correctly describes it. Once we have these things, we can should be able to deliver a neat package to Linus and Alan that will bring both kernel lines up to snuff in the emulation department and document that properly. Then we can take on the bigger stuff. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> Everything you know is wrong. But some of it is a useful first approximation. |
From: James S. <jsi...@ac...> - 2000-03-08 01:24:23
|
> I'll add a pointer to the "Related Resources" section. Great. > The EvStack site at pepsi.visus.com has apparently disappeared. Yes. The papers behind it are at http://zhrodague.net/~jmcc/ggi/EvStack/paper/ > I'm not qualified to write these explanations. If somebody on the list > is, rough up something (plain text is OK) and I'll webify it. They have to come forward and write something. > Well...deliverables 1 and 2 maybe. Hm. We need names for these. I dub > them "Sapphire" (2.2.x emulation patch) and "Emerald" (2.3.x emulation patch). > The more advanced stuff in deliverable 3 ("Ruby") really is new features > and will probably have to wait for 2.5.x if I know Linus. Hey. Linus will not like a lots of new features for 2.3.X. Also it makes more sense to prep the input drivers and fbdev driver for it. > I think we need to first develop a modest, easily comprehensible set of > Sapphire and Emerald patches that bug-fix the emulation, without trying > to hit the larger issues yet. By doing this, and getting these patches > accepted, we'll open the door for more ambitious things later. Yep. > I'm working on Sapphire right now. I've downloaded Dominik's 2.2.1 patch > and am reconciling it with 2.2.12. My objective is to produce a minimal > patch that doesn't include a whole bunch of formatting changes. I'll > test that patch on my stock Red Hat 6.1 system. Great. I will give it a try once you are done. > Once I have that verified, I'll generate a patch for console_codes(4) > that updates it appropriately. Dominik, you could speed things up > by sending me a functional description of your changes. > > Next step after that would be to generate a minimal Emerald patch, > test it, and check that the updated console_code(4) page correctly > describes it. Which is already their unless someone wants to contribute more to his patch. > Once we have these things, we can should be able to deliver a neat > package to Linus and Alan that will bring both kernel lines up to > snuff in the emulation department and document that properly. > Then we can take on the bigger stuff. Agree. > Everything you know is wrong. But some of it is a useful first > approximation. Thats what we physicist say. Remember approximate the cow as a sphere. "Look its a text editor, not its a OS, no it Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
From: <jmc...@li...> - 2000-03-08 18:40:35
|
Eric S. Raymond <es...@th...> wrote: >> Evstack (look in archive) > The EvStack site at pepsi.visus.com has apparently disappeared. It's now at http://zhrodague.net/~jmcc/ggi/EvStack It has my entire CVS repository. -- Jason McMullan, Senior Linux Consultant, Linuxcare, Inc. 412.422.8077 tel, 415.701.0792 fax jmc...@li..., http://www.linuxcare.com/ Linuxcare. Support for the revolution. |