Paul Robinson([EMAIL PROTECTED])@2001.07.12 15:44:32 +0000:
> On Jul 11, "Karsten W. Rohrbach" <[EMAIL PROTECTED]> wrote:
>
> > some rough and spontaneuos ideas:
> > - stripped down python interpreter runs as init
>
> Wow. If you think about it, that's quite a big departure from where FBSD is
> at the moment (or I'm missing the point). You might find a lot more people
> would prefer Perl if you're going to move to this kind of model (however
> it's been so long since I looked at this stuff, you might already be using
> this model, and I don't know about it), but I say ignore them. ;-)
perl might be superior in features at first glance but it has
serious deficiencies in the resulting code style, due to it's nature it
not simply enables programmers to do bad things[tm] but almost enforces
them to do so.
> > - every class has properties which can be preloaded (=unattended install
> > functionality from 'recorded' install session or manually generated
> > setup)
>
> Potentially a hazardous thing to offer. I can see where you're coming from,
> but there are basic questions that would need to be resolved before we get
> into the other issues - e.g. where exactly is the install session going to
> be recorded to? You can't put it on the CD you're pulling from, floppies are
> a pain in the backside, and the early (more confusing parts) are not going
> to have a network available to them. Probably. Is their an existing
> installer that does this, and if so how does it record sessions?
what i was already thinking about was getting some minimal file access
layer -- or rather object access layer -- in place. this would give us
some options where to fetch stuff from and where to write it to. there's
one idea which might not be as obvious to you all which i had some
months ago for storing configuration data of systems after installation
in a safe place (for system restoration and so on). we could multiplex
the config writing to the install partitions on the disk and,
simultaneously, over the network onto a configuration storage server.
due to the object access abstraction it does not really matter what kind
of server this is -- it could be a filesystem hierarchy, ldap, corba,
you name it.
i do not see a problem with giving properties to instances in an
installer, storing them somewhere, and re-use them for subsequent
installs on similar pieces of hardware.
> > so on, perhaps stuff configuration metadata into xml and re-write it
> > to the appropriate (maybe new/different) format -- oops, i said the
> > x-word :->
>
> That's quite a big project. Just getting decent XML parsers in place at
> early stages of install would be problematic IMHO.
as you might have read between the lines of my comment, this would be an
option, and i just mentioned it to keep the folks happy that think they
could solve nearly every single one of their business problems with xml.
> > - remote install dialog ui using ethernet as transport (yay!) would be
> > a nice idea
>
> No, no, no, NO! Please don't do this. Although it seems like a nice idea,
> securing this would be a nightmare, because the only way this could
> realistically be done is if the box decided to do a pure network boot,
> brought over an install image, and then you managed to ssh in or something
> at the right moment. It's too open to abuse. Again, it's a nice idea, but I
> think on a practical level it might be too complicated.
we are talking about installer runtime, when booted from a cd or over
the net or with a boot floppy. i would not enable this functionality
withing the installer of a running system, sure.
> > - making the base system consist of packages would raise the need for
> > package db flagging of non-removable/mandatory pkgs
>
> Yeah, really decent top-notch package management is something sorely missing
> in FBSD. I have several times sat down and thought about writing something
> decent or even lift something from somewhere else, but never got around to
> it. One idea I had was to trojan install so that it could track dependancies
> on standard 'make install' builds. Maybe even put some stuff in 'make'
> itself, or 'configure'. When you think about it, it's not that bad an
> idea. But then, if it was a good idea, somebody else would have done it,
> except they haven't, probably for reasons I haven't thought about.
yes, getting the pkg-plist as a result of the actual install invokation
would make sense.
>
> > - with that step we also could package sendmail and bind out of the base
> > system ;-) hint-hint
>
> sendmail sucks. I think this comes back to the issue of taste. First thing I
> do after an install once I've secured it down, etc. is get sendmail off the
> box and exim in place instead. If that was an option at install time
> (sendmail was never even on the box in the first place) I would jump up and
> down and smile. And stuff.
>
> > - package signature verification would also be a nice thing to have,
> > especially with signature fetching over the net
>
> Still open to abuse. To really secure that you would need to put in measures
> to prevent man-in-the-middle attacks, etc. Good idea though.
i simply do not get your point. you could do that with a http/ssl
enabled fetch client that knows the server certificate -- if that one is
compromised you're hosed, i know, but it improves package integrity
checking and security related stuff. compared to the current mechanism
this would be a lightyear leap.
> <snip big ascii diagram that seems to make sense and disclaimer>
it was written very spontaneously, don't expect it to cover all
aspects...
> Yeah, all seems to make sense. I think python might be a choice that will
> raise some eyebrows, but on the whole it seems pretty cool.
the choice of python for such a thing originates from a few key
features:
- you can strip down the interpreter to a bare minimum, keeping it small
- python2 with batteries-included libs/bindings make it runtime
extendable
- you can distribute bytecode for all the modules which also cuts down
overall size
- it encourages average programmers to stick to a way good style which
keeps the code readable and open to engineering
- in-code documentation
- debugging is much easier than with perl/tcl/...
- it is not just an OO extension of a known language, thus it has no
legacy stuff inside
- it is fast
- it is easily extendable
- you can pickle() any instantiated object (serialize and put to a file)
/k
--
> Motto of the Electrical Engineer:
> Working computer hardware is a lot like an erect penis: it
> stays up as long as you don't fuck with it.
KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie
http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/
karsten&rohrbach.de -- alpha&ngenn.net -- alpha&scene.org -- [EMAIL PROTECTED]
GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46
Please do not remove my address from To: and Cc: fields in mailing lists. 10x
PGP signature
