Re: Problem confirmed (?) and death to lib[h]disk (!) (Re: serious libh linking problems)

Much clearer, thank you. I was confused over the use of my name in the
last sentence. ;)

That said, I totally agree. Getting basic package stuff working is #1
priority, and I even consider the UI stuff secondary, at the point
we're at now (that is, no tvision backend, and a barely working Qt).

But we're getting there. Once I get that linking problem solved, I
think a lot of problems will also be easier to solve, mainly because I
won't have to recompile tclh.static (and dependant modules) each time
I make a change. :)

A.

On Wed Nov 13, 2002 at 04:45:08PM -0800, Jordan K Hubbard wrote:
> I'll restate my last sentence in different terms:  Unless the libh 
> project produces the kind of results that people can see, touch and 
> actually use to install FreeBSD and some set of additional packages, 
> you won't get the kind of help you need to do all of the additional 
> rock-polishing work required, some of which could very well be 
> "enhanced scriptability" and any number of other features that doubling 
> or even tripling the number of bodies available to do the work could 
> bring.  But you're never get there if you don't first release a working 
> prototype, hence doing that is essentially more important than ANYTHING 
> else of architectural or academic value.
> 
> Does that make it clearer? :-)
> 
> - Jordan
> 
> On Wednesday, November 13, 2002, at 03:43 PM, The Anarcat wrote:
> 
> >Exactly. However, scripting is not necessarly for 'the average user',
> >but more for the power user, actually.
> >
> >One might wish to script the disk editor to automagically create
> >fixed-sized partitions or something...
> >
> >That said, I'm really confused by your last sentence, could you
> >make it clearer? :)
> >
> >Antoine <-- yes, antoine
> >
> >On Wed Nov 13, 2002 at 03:34:06PM -0800, Jordan K Hubbard wrote:
> >>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 [email protected]
> >>>with "unsubscribe freebsd-libh" in the body of the message
> >>>
> >>--
> >>Jordan K. Hubbard
> >>Engineering Manager, BSD technology group
> >>Apple Computer
> >>
> >>
> --
> Jordan K. Hubbard
> Engineering Manager, BSD technology group
> Apple Computer
> 

-- 
Imagination is more important than knowledge
                        - Albert Einstein

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE90vYEttcWHAnWiGcRAlO8AJ94t/7NpSuuzC1GxKpH6N3wV94wxQCcDm3k
nttMgImlMj/m6kF7HX+YQMc=
=wmVx
-----END PGP SIGNATURE-----