Re: Flattened GNUstep structure?

[Pascal J. Bourguignon]

Dan Pascu <dan@services.iiruc.ro> wrote:
> On 11 Jan, Helge Hess wrote:
> > The major feature of GNUstep make is, that you can store binaries for
> > multiple platforms while NeXTstep only stored multiple binaries for a
> 
> How does this help an end user? 

What "end  user"? 

If  you ask  for the  secretary  that will  have to  use some  GNUstep
groupware for her  manager, it won't help her and  she won't care. Her
manager less.

If you  ask the  network administrator who  will have to  install this
groupware application  to be used on  the PC of the  secretary, on the
MacG4\MacOSX of her manager, and on the alpha and sparc Linux stations
of the development team, it would help him a great deal.


Asking  for a  flatten directory  structure  here is  like asking  for
binary code being optimized for a specific L2 cache size. Nobody care,
but  the IT  guy  that  will have  to  make it  run  on hardware  with
different  L@  cache  size  and  would not  like  to  see  performance
degrading because  they have too much  or too little  cache. 


> I see it can help a developer build for
> multiple platforms at the same time if he has the tool (cross
> compilers), but an end user will never install multiple platform
> binaries on the same partition. I mean I will not install the freebsd
> and windows binaries on my linux partition, or my linux and freebsd
> binaries when I install on the windows partition (for windows use).

Funny you mention that, but I've just read on fr.comp.os.linux.debat a
question about how to install  two distributions on the same disk, and
whether they could share part of their file system.

More  over, I've  migrated from  (and just  specifying  pertinent OSs)
A/UX, to NeXTSTEP  m68k, to NeXTSTEP i386, to  OPENSTEP, to Linux, and
every  time  I  kept  on  the  same shared  NFS  partition  files  and
applications from  both OSs that I  kept using from one  of my several
computers.  And  it's just an exceptional and  temporary situation I'm
now  with only  one computer  and my  NeXTSTEP files  and applications
being tarballed  on my Linux  system. As soon  as I can port  some old
NeXTSTEP     code    to     OpenStep,    I'll     need     to    store
_on_the_same_NFS_hyerarchy_   my    applications   compiled   for   my
GNUstep/Linux/{i386,alpha}  and OPENSTEP 4.2  new computers  that I'll
buy RSN.


[pascal@triton pascal]$ ls -l /local/nextdev/
total 94611
dr-xr-xr-x    2 pascal   regular      1024 Dec 29 23:26 ./
drwxr-sr-x   32 local    local        1024 Dec  6 15:11 ../
                                                        [...]
-r--r--r--    1 pascal   regular    214093 Jul  4  1995 1995_EOF.tar.gz
                                                        [...]
-r--r--r--    1 pascal   regular      5117 Dec 29 23:24 Bundles.tar.gz
-r--r--r--    1 pascal   regular    550855 Dec 29 23:24 Examples.tar.gz
                                                        [...]
-r--r--r--    1 pascal   regular   1961707 Dec 29 23:25 NSAdvantage.tar.gz
-r--r--r--    1 pascal   regular  17823667 Dec 29 23:25 NeXTAnswers.tar.gz
-r--r--r--    1 pascal   regular  11922489 Dec 29 23:26 Sources.tar.gz
-r--r--r--    1 pascal   regular  18121819 Dec 29 23:24 components.tar.gz
-r--r--r--    1 pascal   regular   7160960 Dec 29 23:24 mk-9.tar.gz
-r--r--r--    1 pascal   regular  25870100 Dec 29 23:26 resources.tar.gz


> Because basically I can only run the binary for one platform on that
> exact platform.
> An exception to this is keeping multiple binaries for one platform and
> different backends.
> What is the use of a deep structure if in 90% of cases you end up with
> a bunch of empty dirs and one single binary hidden in one of them?




Asking for flattening GNUstep implementation details is like asking to
flatten the structure of elf files:

If elf had  implemented /bin/ls as a directory  containing files named
.interp,   .note.ABI-tag,  .hash,   .dynsym,   .dynstr,  .gnu.version,
.gnu.version_r,  .rel.got, etc,  you would  ask to  flatten  it, which
would be as meaningfull than to ask to flatten GNUstep applications.


Now, may  be what you  really want is  to have a nice  executable file
format  like  we   had  on  NeXTSTEP,  with  the   code  for  all  the
architectures stored inside a sigle file.

Well THAT is a good idea.

Only that  it's not the GNUstep  developer who will  implement it, but
the gcc and elf developers.

But in that case, having the experience of MacOS resource forks vs the
NeXTSTEP file packages,  I can say that using  directory structures to
implement such  hierarchical classification of low level  data is much
much  clever, efficient  (at least  in  access, if  not for  copying),
easier, simplier, etc. 


[pascal@triton pascal]$ objdump --headers  /bin/ls

/bin/ls:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .interp       00000013  080480f4  080480f4  000000f4  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .note.ABI-tag 00000020  08048108  08048108  00000108  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .hash         0000022c  08048128  08048128  00000128  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .dynsym       00000460  08048354  08048354  00000354  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .dynstr       000002c8  080487b4  080487b4  000007b4  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .gnu.version  0000008c  08048a7c  08048a7c  00000a7c  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .gnu.version_r 00000030  08048b08  08048b08  00000b08  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .rel.got      00000008  08048b38  08048b38  00000b38  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .rel.bss      00000030  08048b40  08048b40  00000b40  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  9 .rel.plt      000001d8  08048b70  08048b70  00000b70  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 10 .init         00000028  08048d48  08048d48  00000d48  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 11 .plt          000003c0  08048d70  08048d70  00000d70  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 12 .text         0000656c  08049130  08049130  00001130  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 13 .fini         00000014  0804f69c  0804f69c  0000769c  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 14 .rodata       00002c60  0804f6c0  0804f6c0  000076c0  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 15 .data         00000098  08053320  08053320  0000a320  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 16 .eh_frame     00000074  080533b8  080533b8  0000a3b8  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 17 .ctors        00000008  0805342c  0805342c  0000a42c  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 18 .dtors        00000008  08053434  08053434  0000a434  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 19 .got          000000fc  0805343c  0805343c  0000a43c  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 20 .dynamic      000000a0  08053538  08053538  0000a538  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 21 .bss          00000260  080535e0  080535e0  0000a5e0  2**5
                  ALLOC
 22 .comment      000004f1  00000000  00000000  0000a5e0  2**0
                  CONTENTS, READONLY
 23 .note         000001cc  000004f1  000004f1  0000aad1  2**0
                  CONTENTS, READONLY


-- 
__Pascal Bourguignon__    PGP Key ID:      0xEF5E9966                     (o_
mailto:pjb@imaginet.fr    PGP fingerprint: 00 F5 7B DB CA 51 8A AD 04 5B  //\
http://informatimago.free.fr/index         6C DE 32 60 16 8E EF 5E 99 66  V_/

() Join the ASCII ribbon campaign against html email and Microsoft attachments.
/\ Software patents are endangering the computer industry all around the world.
   Join the LPF:     http://lpf.ai.mit.edu/      http://petition.eurolinux.org/