Date: Wed, 13 Nov 2002 15:34:06 -0800 From: Jordan K Hubbard <jkh@queasyweasel.com> To: The Anarcat <anarcat@anarcat.ath.cx> Cc: Alexander Langer <alex@big.endian.de>, libh@FreeBSD.ORG Subject: Re: Problem confirmed (?) and death to lib[h]disk (!) (Re: serious libh linking problems) Message-ID: <66975191-F760-11D6-9957-000393BB9222@queasyweasel.com> In-Reply-To: <20021113220911.GI9829@xtanbul.studio.espresso-com.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I think you may have taken this as a wider mandate for "what's scriptable" than I intended. I also see no reason why the disk editor would be changed by an average user, though I'm sure both of you would also agree that being able to localize it is pretty important. :-) That said, getting out a working prototype should probably be given a higher degree of importance than anything else for all the reasons that Antoine states. - Jordan On Wednesday, November 13, 2002, at 02:09 PM, The Anarcat wrote: > On Wed Nov 13, 2002 at 01:41:01PM -0800, Jordan K Hubbard wrote: >> I think that perhaps the "core" of sysinstall can be compiled but >> everything to do with the user interface, the details of which >> distributions are selected, and so on - just about everything that's >> "policy level" should be scripted. Why? Because it will make things >> 100X easier for the universities and large ISPs and whatnot of the >> world to completely change syinstall's behavior to fit their own >> unique >> needs, say with different default package sets, menus and UIs in >> different languages or different layouts, you name it. I would only >> expect those parts of sysinstall which are so "core" and essential and >> nature that nobody would ever want to customize them to be compiled. > > That is all well and nice in words, but I think there are more > pressing matter for now. > > Of course everthing *can* be scripted. But why script the disk editor? > Or if we script it, why would it even be part of libh's core? > > I think a disk editor is outside libh's scope. It can be pretty easy, > once we get dynamic linking back online, to make a script load a > (third party?) disk library and script from there. But the disk library > is too much for libh for handle, I think, especially with the GEOM > changes. > > So, yes, I agree that libh must provide a UI-indendant scripting > language but it doesn't mean it must provide every damn feature > scripts might need. > > 2 things: > > - UI library > - package system > > rest is third party loadable modules. heck, if we can't make it third > party, how can we possibly pretend to extend libh in any way?? > > That's what I'm willing to maintain. If anything else breaks, I think > it shouldn't hinder libh development, which is hard enough as it is > now. > > Sorry for the ranting, but things are getting pretty hard now. I've > been struggling for a pretty good while and now that we're almost > getting to have a semi-working package system, I'm stopped by yet > another thing. It's really annoying. > > Cheers, > > A. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-libh" in the body of the message > -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?66975191-F760-11D6-9957-000393BB9222>