Date: Thu, 12 Jul 2001 18:06:07 +0100 From: Paul Robinson <paul@akita.co.uk> To: "Karsten W. Rohrbach" <karsten@rohrbach.de> Cc: Terry Lambert <tlambert2@mindspring.com>, Bill Moran <wmoran@iowna.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: getting rid of sysinstall - Was: FreeBSD Mall now BSDCentral Message-ID: <20010712180607.C93119@jake.akitanet.co.uk> In-Reply-To: <20010712180421.F91396@mail.webmonster.de>; from karsten@rohrbach.de on Thu, Jul 12, 2001 at 06:04:22PM %2B0200 References: <20010706144935.A61843@xor.obsecurity.org> <3B4650D0.97F10B83@bellatlantic.net> <20010707002340.B16071@widomaker.com> <20010707004731V.jkh@osd.bsdi.com> <3B49F8D5.2C9BFA73@mindspring.com> <3B4A0124.26025FB5@iowna.com> <3B4A1423.E8E365E@mindspring.com> <20010711190247.D52923@mail.webmonster.de> <20010712154432.N53408@jake.akitanet.co.uk> <20010712180421.F91396@mail.webmonster.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 12, "Karsten W. Rohrbach" <karsten@rohrbach.de> wrote:
=20
> perl might be superior in features at first glance but it has=20
> 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.
A sloppy programmer in one language is a sloppy programmer in all
languages. Just because the language looks neater and more formal, doesn't
mean it's any more 'correct' (and yes, my BEng is Software Engineering and I
get all evangelical about this).
The advantage to Perl, if done properly, is that it allows more people who
already know the language to become involved in improving the code. However,
we run the risk here of getting into a flamewar over language preference.
=20
> 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.
Which means to 'playback' the install session you would need to get
networking up along with something that will talk ldap/corba/whatever before
you had even allocated disk space. Turns things around a little bit, but
it's a reasonable idea if it can be done.
=20
> 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.
Neither do I, I just think we need to clarify where the data is being
stored, how, and how that data can be brought over to a machine being
installed.
=20
> 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.
Heh. I'm behind on that one - bought 'Learning XML' this morning. I'm sure I
will become an evangelist of that next.
=20
> yes, getting the pkg-plist as a result of the actual install invokation
> would make sense.
In fact, I might knock up some code for that later. Unless somebody else
points out where it's going to go wrong, of course.
=20
> > > - package signature verification would also be a nice thing to have,
> > > especially with signature fetching over the net
> >=20
> > Still open to abuse. To really secure that you would need to put in mea=
sures
> > to prevent man-in-the-middle attacks, etc. Good idea though.
>=20
> 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.
There is a problem here in that install media effectively becomes useless if
the server certificate ever gets compromised or changed. I see what you're
saying, I'm just not sure if the long-term usability issues are being
addressed properly here.
=20
> 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
As you can with Perl, or just write it in C in the first place. ;-)
> - in-code documentation
Ummm... I'm pretty sure all languages to be considered for the task would
have the capability to use comments in the code. :-)
> - debugging is much easier than with perl/tcl/...
Debatable.
> - it is not just an OO extension of a known language, thus it has no
> legacy stuff inside
'Legacy stuff' sometimes is a good thing to have. Again, it depends on what
exactly you mean.
I understand all your reasons, I would just be worried that you're making
the choice because it's your favourite language, when ultimately we should
be thinking about what the rest of the world would like to use. Python is a
good language, I would just reccomend not jumping in right away.
--=20
Paul Robinson ,---------------------------------------
Technical Director @ Akita | A computer lets you make more mistakes
PO Box 604, Manchester, M60 3PR | than any other invention with the=20
T: +44 (0) 161 228 6388 (F:6389)| possible exceptions of handguns and
| Tequila - Mitch Ratcliffe
`-----
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010712180607.C93119>