Re: Grand Unified System Installer (hurd distro) + my taughts and comments - new to hurd contributions, only taking my head out of the sand now.

[olafBuddenhagen]

Hi,

On Thu, Jul 23, 2009 at 11:29:19PM +0100, Ivan Malone wrote:

> This will be a long post. [...]

As you are talking about several rather unrelated things, it would have
been much easier to handle if you had sent several smaller mails
instead...

> I've managed to get Hurd built from source many times

You mean cross-compiled? Congrats -- few of those who try this actually
succeed :-)

> 1) Is the reason for using dpkg on hurd atm to manage packages because
> of the hurds current association with Debian,

Debian is simply the only project presently providing a viable GNU/Hurd
distribution, so that's what we are using. (And greatful for it.)

The Hurd itself is not tied to dpkg in any way.

> 2) Is the GNU Package Management system thats under development realy
> on the right track in your opinion?

Not sure what you are referring to. You mean the one discussed on the
gnu-system-discuss@gnu.org list?

> Do you see it been the final package management system on hurd...

It is supposed to be used on the official GNU distribution. That doens't
mean that other GNU/Hurd distributions can't use different package
managers.

> 3) The Hurd is UNIX (POSIX) compatible - have you found anything in
> the current draft POSIX.2 (i believe) standards that don't seem to
> provide enough room, or perhaps, restrict development on Hurd in
> anyway, like implenentation of future ideas?

I don't think new POSIX versions will make things worse. (In fact, there
are some slight improvements related to PATH_MAX AFAIK.)

POSIX itself is quite problematic, making it rather tricky to offer full
compatibily while also leaving room for moving forward. That's the price
we pay for easy migration.

> Or is Hurd only concerned with the current POSIX standard in that it
> suits hurd at the moment to stick to it.

The GNU system was always meant to be UNIX-compatible. POSIX essentially
just standardized UNIX, so it's easier to say what "compatible" means.
In this sense, POSIX compatibility is essential for the GNU kernel.

> One aspect of hurd that I want to get involved in is File Systems. I
> love that everything is decentralized. It makes no difference to me if
> the objects are remote or localy hosted.

Not sure what you are referring to... We presently have no framework for
working with remote objects :-(

> 4) What kind of filesystem to you envision Hurd finally using as its
> default, I dont see it been ext2 or ext3.

This is indeed something I have mused about in the past.

One important aspect of file systems on the Hurd is that they encourage
implementing all kinds of data structures as filesystem hierarchies.
However, traditional disk filesystems are rather unsuitable for storing
such hierarchies directly: using a really large number of very small
objects is extremely inefficient; while storing them pre-serialized
(e.g. as XML files) is very inefficient when updating individual items
(you essentially have to rewrite the whole file), or requires very
complex handling to implement some kind of database layer on top of
plain files.

Ideally, we want a disk filesystem that can natively store and update
large hierarchies of small objects efficiently. btrfs is certainly an
improvement comparead to ext2+ in this regard -- whether it's ideal I'm
not sure. For the time being, it's certainly a more realistic option
than inventing our own disk filesystem... There are more important
things to do for us :-)

Another aspect of filesystems would be relevat for my vision of a
Hurd-based desktop system: for proper session management, a filesystem
with recursive snapshotting would be very helpful. btrfs does support
global snapshotting, but I'm not sure about recursive...

> Mikel Olasagisti (excuse if i spelt it wrong) was working on
> Gentoo-Hurd and I too have an interest in using portage (or something
> new based on portage/apt mix) but I believe that development has
> stalled or stopped but I'll be going back over it soon and hopefully
> get his and others taughts. Gentoo is not my distro of choice but I
> like its philosphy of installing from source. 

The Hurd wasn't really stable enough for a source-based distro to be
feasible at that time. This has improved a lot though in recent years,
so it would be interesting to revisit this now :-)

> I was also wondering in general about the future of operating systems
> in general. For example, ten years from now I'm predicting that the
> dividing line of which operating system you use will be irrelevent
> when it comes down to making a choice between applications for
> databases, games, desktop publishing, multimedia, whatever. Mono,
> Java, Google, IBM are all on to big things but again, something just
> doesn't seem right to me about it all. I think the role of the
> operating system will come down to just managing the local computer,
> providing means to communicate with devices (weither remote or local)
> and the actual software the majority of people use will either be
> service based (ie: running remotly somewhere with some interface to
> connect to) or universal like Java, Mono

These are valid concerns -- I sometimes wonder myself whether by the
time we get a nice desktop operating system, traditional desktop
computing won't have become irrelevant :-(

I certainly do hope that they won't, as this is fundamentally
incompatible with the goals of free software -- but I wonder whether the
majority of people really cares enough about giving up control over
their computing... After all, most people don't mind using proprietary
software; so using network-based services instead won't make much
difference for them :-(

As for middleware platforms like Java, I dislike these very much. It
makes no sense to put another platform on top of the operating system --
it is the operating system's job to provide a platform for running
programs. Additional frameworks only make integration harder. If there
are any shortcomings in the operating system, these need to be fixed,
rather than worked around by piling layers of frameworks on top of it.
The Hurd's extensible architecture should help with this.

> Would it be possible in Hurd... from a users environment (installuser
> account) to setup the envirnment in such a way as a system mounted and
> booted into it (such as ubuntu) could not see the underlying Hurd and
> continue as normal? - ie: advanced chroot in the broadest loosest
> sense/
[...]
> The Other Distro wouldn't have to worry about device drivers as the
> Hurd system would provide compatibility layers through interfaces
> enough for the other system to work using its stock drivers for the
> likes of disk, network etc. - but of course, provide some method for
> the other distro to loads its only specific drivers if need be.
[...]
> This could possibly decrease the size of potentional distributions
> live cd's as it wouldn't need so much to get up and running, the
> grub/Hurd combo would take care of it (and provide a real world,
> working example of a hurd system to begin with ??? a proof of concept
> that hurd is real, useable and not just a hackers toy). 

As much as I'd like to see some real-world turnkey solution based on the
Hurd -- showing that it's not just a toy -- I have some doubts about
what you are envisioning being a good cadidate for that :-(

It rather sounds like the job for a traditional full virtualization
solution, like Qemu or KVM or VirtualBox or Xen etc. -- and I don't
think the Hurd would be a good platform for that. The architecture
doesn't offer any advatages in this case; and you would have to make
some of these virtualization solutions actually work on the Hurd
first...

-antrik-