Re: [kvm-devel] [Qemu-devel] Making qemu images executable (and store command line arguments in them =P)

[Christian Brunschen]

On 19 Aug 2007, at 12:08, Avi Kivity wrote:

> Markus Hitter wrote:
> > Am 19.08.2007 um 12:35 schrieb Avi Kivity:
> >
> > > - this deviates from standard Unix (and Windows) practice.    
> > > Arguably the OS X way is superior, but qemu is perhaps not the  
> > > best  vehicle to introduce it to other OSes.
> >
> > NeXTstep introduced this into the Unix world and GNUstep uses it   
> > today. So, there's prior art.
>
> Nothing on my machine uses it today, as far as I can tell.
>
> (I don't oppose this use in Linux -- I think it's an excellent way  
> to package apps -- but I'm not sure qemu should be the first app to  
> do this.  It needs buy-in from distros)
>
> ((but we're actually talking about something slightly different;  
> packaging data vs packaging apps))

This has been the preferred way to package _any_ 'bundle' of data,  
whether it be an application, a framework, a rich-text file with  
images (the '.rtfd' format), since its introduction in NeXTStep, and  
ever since then it has been and remains the preferred way in  
OPENSTEP, Mac OS X, and GNUStep.

There is *ample* precedent, so qemu would not be the first app on  
Linux or on any other Unix either. Remember also that OpenStep was  
available for Solaris for a while, and that NeXT/Apple's WebObjects,  
which included a development environment and various applications,  
also ran on Solaris, HP-UX and even on Windows NT and 2000. So this  
NeXT/Apple-style bundling of related files into a directory which is  
then treated as a single unit has been used successfully on a wide  
variety of systems, including Linux and any other plaftorm that can  
run GNUStep, as well as various Unixen and Windows. And I am talking  
about this very much in the sense of packaging *data*, not 'just'  
applications.

So there is ample precedent, it is a successfully and widely used  
idea that has been previously successully used on multiple platforms,  
and in fact is the standard on the most widely used unix today (Mac  
OS X).

Plus, there's ample precedent for similar things: Many administrators  
keep various interconnected configuration files for (for instance)  
apache in a directory that is apache-configuration-specific,  
effectively treating 'apache configuration' as a single unit with  
multiple parts - the parts (configuration files for specific aspects)  
being bundled together in a directory to show the fact that they are  
a unit and do belong together.

Best wishes,

// Christian Brunschen