Re: SEUL: Documentation: info & postscript

["Luka@pop3.aracnet.com (Peter)" <luka@mit.edu>]

yeesh.  power goes out, mit crashes, and when i come back....


texinfo: do a search for texi2html - it's a perl script that converts
 texinfo docs to html.  it's not perfect, but if we want to do this, it
 can be fixed.

postscript: what can i say?  ps was meant to be printed.  (and it displays
 reasonably well for me at 1280x1024 or higher resolution.
 you can probably can around the source in some cases to change the font -
 but i think it would break a lot in the general case.
 as for converting ps to something else (eg html) - not going to happen.
 if you have the source the the ps (tex, fig, whatever), then that can
 usually be compiled to something other than ps, though.
 (and if someone wants to write a better font antialiasing routine for
 ghostscript, be my guest...)


in response to dave, which was in response to other recent stuff:

dave wreski wrote:
>1.  It seems like we are worring about the small little details too early.
>Although things like compiling the kernel automatically are important,
>don't we need a foundation to start with, before we worry about how the
>user will see the interface?

correct.  see group organization stuff i just sent out.
i am working on system architecture right now, and should be mailing a lot of
stuff out by the end of today for feedback.

also many of these details were brought up last time the list
exploded - please read the archives, folks.


>2.  With all the talk about GUI apps, etc, has anyone thought about simply
>using a web browser?  Whats wrong with having httpd running on all boxes,
>and using this as a backend for all configuration applications?  You could
>even use it as a replacement for GNUs 'info', and possibly a replacement
>for man pages as well..

see omega's reponse about discussion that's been going on about this.
this is roughly what we are planning on doing, though for various reasons
we want to use an extended html format and a custom hacked browser.
you will hear much more about this really soon.


>3.  How many of us are kernel programmers?  If there aren't that many/any,
>should we be so concerned with modifing the auto-detection mechanism of
>the kernel, to probe for devices?

nod. i know kernel.  but that doesn't mean i should hack it for seul, or that
anyone else should.  question is: who will support kernel-based modifications?
we should base the decision to do kernel hacking on whether it is not possible
to do something otherwise.
also, we should exploit modules.  modules are great.  they are what will keep
kernel rebuilds and failures from happening for our users, imho.


>In summary, I think we need to look at what we already have to work with,
>start simple, and strictly define our goals, before we do any actual
>development.  Have we already defined specifically our end goals?

see the white paper i wrote for a rough outline.  it's on the web.
note that it's a bit old and outdated on some points.  but the point is
it covers our general goals - the first section or two is of most interest.

the next thing i'm working on is what the system should look like when it's
finished, followed by module specifications, and a plan for incremental
development.

stay tuned for more,

-luka
----------------------------------------------------------------------------
Simple End User Linux Mailing list
To be removed from this mailing list send a message to majordomo@txcc.net
with the line
unsubscribe seul-project
in the body of the letter.
----------------------------------------------------------------------------