Subject: Re: Installing on an 4 MB A5000

From: James Craig <[email-masked]>
Date: Sat, 18 Apr 1998 08:18:58 +0000 (GMT)

On Fri, 17 Apr 1998, David Alan Gilbert wrote:

>Matthew Wilcox wrote:
>> 
>> Hans Bogaards
>> > I realised that, but I was wondering would it work with two diskdrives? One
>> > for the root-disk and one for the supplemental disk
>> 
>> It /should/ work.  It will probably require a slight change to the
>> rootdisc, which I'm willing to do for you.  Actually, it might give you
>> the opportunity to put the disc in a different drive, it's a while since
>> I ran the installer.
>
>It might work; but it won't let you install - 4MB of RAM just isn't enough
>for the standard RedHat installer to do its stuff. It can't even turn swapping
>on before it runs out.
>
>At the moment there is no easy method of installing on a 4MB machine.
>Non-easy methods include installing over the network using a kernel which
>has NFS-root and putting a mkswap and swapon at the start of the /etc/rc's
>and installing using a PC onto a PC hard drive and transferring the drive;
>you'll have to do the same swap trick.
>Neither of these are for the faint hearted; but it is possible - just.

Here's a serious thought.
The Slackware installer works in 4M on the ix86 architecture - anyone feel
like recompiling Slack for the ARM? It should just be a case of setting up
the cross-compiler as the default compiler, and then doing a SlackBuild
command in the root of the slack source tree.
The other thing is that you can install slackware packages without using
the installer, if you really need, since they are just .tar.gz's with a
few extra files included. Much nicer than that horrible RPM thingy. :)

>> > Further, is it possible to (temporarily) install a HD diskdrive from a PC
>> > in my A5000 with a standard PC-diskdrive cable or do I need special Acorn
>> > stuff for this?
>> 
>> Should work straight off.  I never did - I had a second hard disc in place
>> of the 2nd floppy disc drive.
>
>Be careful - the Acorn ADFS is pretty hopeless compatibility wise; I've
>seen it get pretty confused with some harddrives - to the point where RiscOS
>won't come up. I think its the luck of the draw as to whether a particular
>manufacturers drive will work or not.
Um, IDE, ST506, or SCSI?
All the ST506s I've tried have been fine, and I don't remember seeing an
IDE drive break except as a 2nd drive (some IDE HDDs just /do not/ work
together. Not nice, but it's hit me 3 times so far) - so is it an ADFS
thingy (in which case it shouldn't affect linux once you've got it booted
up) or is it a dodgy-HDDs-not-working-together-job?

>Dave
>
>-- 
>----------------------------------------------------------------------
>- Dr. David Alan Gilbert - WARNING! This is a beta release .signature-
>- Work:    dg @ cogency.co.uk        - +44-(0)161-428-9444           -
>- Home:    gro.gilbert @ treblig.org -                               -
>----------------------------------------------------------------------
>unsubscribe: body of `unsubscribe linux-arm' to [email-masked]
>
-- James Craig
   <[email-masked]>

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Dickon Hood <[email-masked]>
Date: Sat, 18 Apr 1998 12:05:57 +0100

In message <[email-masked]> you wrote:

: On Fri, 17 Apr 1998, David Alan Gilbert wrote:

: Here's a serious thought. The Slackware installer works in 4M on the ix86
: architecture - anyone feel like recompiling Slack for the ARM?

Would be nice...  IMHO, RH is too SysVile.

: >Be careful - the Acorn ADFS is pretty hopeless compatibility wise; I've
: >seen it get pretty confused with some harddrives - to the point where
: >RiscOS won't come up. I think its the luck of the draw as to whether a
: >particular manufacturers drive will work or not.

: Um, IDE, ST506, or SCSI?
: All the ST506s I've tried have been fine, and I don't remember seeing an
: IDE drive break except as a 2nd drive (some IDE HDDs just /do not/ work
: together. Not nice, but it's hit me 3 times so far) - so is it an ADFS
: thingy (in which case it shouldn't affect linux once you've got it booted
: up) or is it a dodgy-HDDs-not-working-together-job?

IIRC, from talking to Simes, it is an ADFS problem (not specifically
Filecore) which was fixed with the 'Large filecore' released in Risc OS 3.6
(not to be confused with the 'Large filecore' to be released with RPCII).  I
bought a drive which wouldn't work under the older one; AFAICR we bodged
around it by using a pull-[up|down] resistor across two pins.  Very dodgy;
don't try this at home ;-)

ObLinux: Linux should cope with such drives, assuming I've got that right.

-- 
Dickon Hood

I've now managed to find my .signature file, normal service
will be resumed when Connex South Central get their act together.
We apologise for the inconvenience in the mean time.
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Sat, 18 Apr 1998 09:14:28 +0100 (BST)

> few extra files included. Much nicer than that horrible RPM thingy. :)

Here's a few facts:
*	The RedHat installer works in 4MB on the x86 architecture.
*	The RedHat installer works in 4MB on the RiscPC architecture.
*	The RedHat installer does not work in 4MB on the A5000 architecture.

The reason?  The old machines have a limited number of pages (128 if you've
got 4MB) and with a 32k page size.  This all adds up to not a lot of pages
per process after the kernel has built, and hence the problems.  In 4MB without
swap, you can just about get away with a shell and a daemon before you
hit the out of memory.  There just aren't enough pages at a fine enough
granularity.

No matter what installer you use, you're going to get this problem.

Besides, RPMs are much nicer...  The binary ones contain all info to do
with the package, including install and uninstall scripts.  They also
contain a description of the package, and a signature (mine don't) to
verify that the packages are still sound.

The source RPMs contain all the info to rebuild the binary RPM.  In fact,
you cannot have a source RPM without having a binary RPM.

The RPMs have version and release numbers in, and they have
interdependencies, such that the installer can say to itself: 'so you want
to install this perl script do you?  have you installed perl already ?'
If you haven't, it'll warn you.  It'll also warn you if you attempt to
remove a package (eg perl) that has other packages using it.

I've had this discussion with someone at work, and they saw the light... ;)
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.uk.linux.org/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Sun, 19 Apr 1998 11:34:23 +0100 (BST)

>From what I remember of Slackware, it was worse than RH.  Last time I looked at
Slackware, it had all sorts of problems *because* it wasn't intelligent enough
with the init daemon.  For instance, when you boot, it would mount the local
filesystems, turn on swap etc before entering a run level.  Then, if you shutdown
to single user mode, it would turn swap off and unmount all filesystems.  Then
when returning to a run level, it totally and utterly forgot that it had unmounted
the filesystems.

The RH init style may be SysVile-like, but at least *it works* and it is
*extendable*.

However, maybe Slackware has improved since I last looked at it.

> don't try this at home ;-)

Indeed, some drives (notably Western Digital drives) to something very silly -
if you tell the drive to disable interrupts, it will !!assert!! it's interrupt
line.  This would then cause RiscOS to hang.

I'm not certain, but I think that Linus may use this to it's advantage when
resetting the drive... ;)
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.uk.linux.org/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: James Craig <[email-masked]>
Date: Mon, 20 Apr 1998 10:44:00 +0100 (BST)

--
James Craig <[email-masked]>
            <[email-masked]>

> *	The RedHat installer does not work in 4MB on the A5000 architecture.
It's well dodgy on 4M on an x86. I've tried it. :) 
> hit the out of memory.  There just aren't enough pages at a fine enough
Yep, I know about this problem. It's a bit of a problem (understatement of
the century) but we're more likely to be able to manage when the installer
is just a tar+gunzip, instead of some weird format that stores huge heaps
of completely useless info. 
> No matter what installer you use, you're going to get this problem. > 
The slackware packages include the scripts too - If you look closely at a
slackware package, it contains a install/script file usually which handles
installation. Most slackware packages uninstall fairly cleanly too. The
other *BIG*, in fact *HUGE* advantage is that you can get away with no
installer whatsoever. The good old fashioned sash shell (stand-alone
shell) includes tar in it - and compiles perfectly for the ARM leaving
bucketloads of RAM free even on a 4M machine. You can just use it's
built-in tar command to unpack the slackware packages - it works great.
> you cannot have a source RPM without having a binary RPM.
Woopee. Hmm... methinks slackware source dir and the magic SlackBuild
files. :)
> remove a package (eg perl) that has other packages using it.
Interdependencies are much overrated. Installing RH and debian, I spend
half my time overriding the bloody things because stupid people saw fit to
make, e.g. tcl-7.4 and tcl-7.5, completely seperate from a dependencies
point of view. Right now, ARM linux is a real pain in the butt to get
working on older machines. I don't really think people who are smart
enough to get it to even *boot* are going to have much trouble figuring
out that the need to install perl before they can use a perl script. Not
to forget, of course, RPM is truly hideous to use anyway. Trying to do
anything other than one of the predefined action is seriously fiddly, and 
you don't stand much change of getting an RPM port to other OSs to let
you modify packages before installing them - e.g. seperating individual
files out to fit them onto 720K floppies.. Also - removing a package which
other programs are using isn't smart usually - but you need to do it to
make a decent job of upgrading versions on something. I'd much rather it
just shut up and got on with it. :)
> I've had this discussion with someone at work, and they saw the light... ;)
My commiserations to your friend, losing his soul to the dark side of
Linux. He's fallen in with evil companions. ;)

-- James Craig

---

From: James Craig <[email-masked]>
Date: Mon, 20 Apr 1998 10:48:16 +0100 (BST)

> when returning to a run level, it totally and utterly forgot that it had unmounted
It's also so nice and uncomplicated that it causes no trouble to 99% of
people. BTW, that bug is one I haven't encountered, and I've been using
Slackware since 1993. :)
> The RH init style may be SysVile-like, but at least *it works* and it is
Um, slack isn't non-extendable just because you have to add stuff to the
end of /etc/rc.d/rc.local occasionally. And, of course, it *DOES* work. :)
> However, maybe Slackware has improved since I last looked at it.
Probably. Slackware is so simple in it's setup though that it would be
hard to improve on. 
> resetting the drive... ;)
Pass. I wouldn't know. The last time I tried writing IDE device drivers, I
managed to send the drive a format command instead of a verify one and
totaled the first 2 tracks. I'll get around to doing them again, but not
until I have a spare hard-drive I don't mind losing everything on. :)

-- James Craig

---

From: Andrew Bower <[email-masked]>
Date: Mon, 20 Apr 1998 11:05:22 +0100 (BST)

> It's well dodgy on 4M on an x86. I've tried it. :) 
And me:)

I totally agree.  Slackware whips Redhat:  It works.

A slackware distribution for ARM Linux would be a very good thing. 
Especially since most arcs are underspecified compared with PCs.

I'd be happy to help too, although no guarantees.
(i.e. I don't have my arc with me and it doesn't have enough hd :(  )

Andrew

---

From: Alan Cox <[email-masked]>
Date: Mon, 20 Apr 1998 11:11:46 +0100 (BST)

> It's well dodgy on 4M on an x86. I've tried it. :) 

Its fine in 4Mbytes on x86 unless you use ramdisks. Its a concious decision
that RH chooses to ship 8Mbyte minimum setups.

> of completely useless info. 

Actually for a minimal installer rpm is just cpio+gzip (tar is unsuitable
for several reasons including path length limitations and taking more
space)

> installer whatsoever. The good old fashioned sash shell (stand-alone

Your installer is /bin/sh and gnu tar. Thats _bigger_ than the minimal rpm
installer, even before I point out you need awk,sed, and other bits

> point of view. Right now, ARM linux is a real pain in the butt to get

Which is correct. They aren't compatible.

> to forget, of course, RPM is truly hideous to use anyway. Trying to do

Run an ISP with 30+ machines to maintain or deal with code porting and
cross platform maintenance and you'll understand why RPM is an absolute
gift. At home I just type

autorpm

and all my boxes are up to date.

For a code point of view the SRPM packages contain ChangeLogs and patch
sets as well as per architecture rules. Updating an original package change
normally involves flipping the tar file to the latest from the author,
removing any patches now accepted by them and telling it to rebuild.

> files out to fit them onto 720K floppies.. Also - removing a package which

RPM uses zlib to read data streams. Since RPM streams data you can install
RPM files direct of tape - that means you can add a deblocker and install
an rpm split over floppies quite easily.

Alan

---

From: Alan Cox <[email-masked]>
Date: Mon, 20 Apr 1998 11:13:25 +0100 (BST)

> end of /etc/rc.d/rc.local occasionally. And, of course, it *DOES* work. :)

Except for people who don't know or wish to know how to edit configuration
files, people who want to manage boot order and what boots when. There is
a reason everything in the world but Slackware uses Sys5 style init.

Alan

---

From: Alan Cox <[email-masked]>
Date: Mon, 20 Apr 1998 11:15:31 +0100 (BST)

> Especially since most arcs are underspecified compared with PCs.

This I have to see.. 

> (i.e. I don't have my arc with me and it doesn't have enough hd :(  )

You need about 4Gig of free disk to work effeciently on a distribution
and preferably a second disk and machine to keep feeding your latest
attempts too.

You also need to budget people for support and maintaining of each package
you ship.
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: David <[email-masked]>
Date: Mon, 20 Apr 1998 12:26:18 +0100 (BST)

> for several reasons including path length limitations and taking more

Can you extract RPMs with standard UNIX commands?  If so, could you be a
bit more explicit as to how you do this...I've been trying for ages.

> installer, even before I point out you need awk,sed, and other bits

It's perhaps not the wisest thing to say but: I've installed NetBSD/arm32
on my system and all the files there were .tar.gz.  Which has two key
advantages for me: (a) I know instantly how to unpack the things (b) I can
unpack them under RISCOS if necessary.  Also, for many things I haven't
noticed the need for awk, sed, perl etc.  (But I can get them running
under RISCOS too, if I need to.)

> an rpm split over floppies quite easily.

Can you not do this with tar?

Just a thought,
David.

---

From: David <[email-masked]>
Date: Mon, 20 Apr 1998 12:41:37 +0100 (BST)

> > Especially since most arcs are underspecified compared with PCs.

Perhaps you might.  I happen to think it'd be a good idea too.  I think
I'll have to look at the details, but if anyone's going to do this, count
me in.  (Well, after exams, anyway.)

> and preferably a second disk and machine to keep feeding your latest

Not a problem as far as disk space goes - 6Gb, and *two* spare machines.

I'm currently in Cambridge and would be looking at doing this over the
summer/beginning of next term.  Is anyone *seriously* interested in this
project?  Anyone willing to help?

David.

---

From: Alan Cox <[email-masked]>
Date: Mon, 20 Apr 1998 13:20:58 +0100 (BST)

> bit more explicit as to how you do this...I've been trying for ages.

Take a look at rpm2cpio. Basically you pull off a header block, gunzip it
and you get a cpio

> unpack them under RISCOS if necessary.  Also, for many things I haven't

tar cannot handle some things - try a 4K file path in tar for example. THats
why cpio is used. 'pax' is a portable tar/cpio.

> under RISCOS too, if I need to.)

For install scripts... 

> Can you not do this with tar?

Yes, and cpio 8)

---

From: Philip Blundell <[email-masked]>
Date: Mon, 20 Apr 1998 13:07:28 +0100

>bit more explicit as to how you do this...I've been trying for ages.

rpm2cpio will strip the header off and leave you with a standard cpio archive. 
I'm sure you could engineer your own program to do this if you wanted to.  I 
haven't looked at the rpm format in detail but I doubt it's hard - you might 
even be able to do it with dd, od and a bit of shell script.

p.

---

From: Alan Cox <[email-masked]>
Date: Mon, 20 Apr 1998 13:25:49 +0100 (BST)

> me in.  (Well, after exams, anyway.)

I think you are out of your tree personally, but I wish you best of luck
anyway

---

From: David Alan Gilbert <[email-masked]>
Date: Mon, 20 Apr 1998 14:23:39 +0100

Hi All,
  While steering clear of the holy RH/Slackware war I think one
soloution to the RH install on a 4MB machine would be to
have a pre-install disc which just has a hacked up swapon
and mkswap and perhaps enough to load a module for the SCSI
discs. So you boot that, it sets up the swap and then you
flip the RH install disc in and boot that.

  What do you reckon?

<Back to the war>
RH is a nice installer - when it works; but it really has a nasty
habit of coming to the end of the installation having completely
ignored an important error and leaving the system half installed.
And also it tends to install in no useful order; it doesn't install
critical stuff first, so when you do get an error it tends to be something
useful like init which is missing (but at least emacs was installed - hmm...)

Slakware just works; its still the installer I believe is most likely
to work given a-random-machine.

Dave

---

From: Andy Fawcett <[email-masked]>
Date: Mon, 20 Apr 1998 14:40:53 +0100

> flip the RH install disc in and boot that.

Well, since I can't currently install onto my 4MB A5000 for just these
reasons, I think it's a good idea. I'm going to be upgrading to 8MB one
of these days, but the absence of all installation disks for the A5K
still makes installation problematical.

I, for one, would welcome any work done to help us poor memory-starved
individuals...
-- 
Andy Fawcett
Writing from work, but writing for himself
http://www.afawcett.demon.co.uk/
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Mon, 20 Apr 1998 14:40:57 +0100

>flip the RH install disc in and boot that.

Trouble is you need to have already partitioned the disks.  If you can get 
fdisk, mkswap and swapon to run in the amount of real RAM you have then you 
ought to be in business - you could even roll that functionality into one 
binary if you got really desperate, say on 2MB machines. :-)

p.

---

From: Alan Cox <[email-masked]>
Date: Mon, 20 Apr 1998 15:01:27 +0100 (BST)

> flip the RH install disc in and boot that.

The RH install disk runs off a ramdisk because it needs to load some
things from floppy then allow you to change floppy. If your root is
only fd0 you can't of course do this.

Putting it on an ADFS partition or using a minimal initial bootstrap
install should work for a 4Mbyte machine. 

Alan

---

From: Matthew Wilcox <[email-masked]>
Date: Mon, 20 Apr 1998 15:13:40 +0100 (BST)

David Alan Gilbert
> flip the RH install disc in and boot that.

I reckon the idea you mentioned previously in private mail is better.  It
should be almost trivial to look through the getpartns utility supplied
with IscaFS, figure out where the swappartition is and write the two words
there which Linux requires.  Hmm.. then does the RH installer swapon
early enough?  Or can it be made to?

-- 
Set Alias$Case Set Alias$[ |||| |MSet Alias$Otherwise Set Alias$[ \ Matthew
"" |MSet Alias$When If %0=%%0 Then Set Alias$[ "" ||MIf %0=%%0    \ Wilcox
Then Set Alias$Otherwise Set Alias$[ |||||||||||||||| ||MIf       \
%0=%%0 Then Set Alias$When Set Alias$[ ||||||||||||||||
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Russ King <[email-masked]>
Date: Mon, 20 Apr 1998 18:23:11 +0100 (BST)

> even be able to do it with dd, od and a bit of shell script.

Indeed, you can do it with standard unix commands - dd, gzip and cpio.

I originally did want a slackware-like distribution, but after going through
Slackware's install for about a total of 10 hours on various machines, I got
very pissed off with it.  When I used it, it required complete attention - no
chance to do anything else for 2 hours.  This is not what I call a viable
distribution.

RedHat on the other hand does things the *right* way - it asks you what you
want to install and then installs it.  Meanwhile, you can leave the machine
to it's own devices..

The other point I'd like to make is that there was *absolutely* no way to create
the boot disk for slackware on the A5000 - all the necessary binaries *just*
*did* *not* *fit*.  It was so bad, that I even contemplated writing a separate
installer for it.

Someone then suggested using RedHat, and initially I didn't like it.  However,
it's not as horrible as you might think it is.  The package system is logical
and far better than tar.  It uses less memory space and disk space than slackware,
all of which a 4MB machine needs.

Dave's concerns on it not reporting errors I believe to be a bug - it now
reports errors if it can't install everything.  However the installer does have
a few bugs in.

Because of this bugs, I have disabled the automatic reboot in the init daemon,
to prevent it looking although it's installed itself.

As far as I am concerned, the differences between RedHat and slackware is the
same as between RiscOS and Windoze.  RedHat, like RiscOS performs it's function,
and does it well (although I will admit to RedHat having bugs in).  Slackware,
like windowze, is less flexable once installed, and requires your complete
attention at every stage.

For all of these reasons, I would see time spent on the package front of Slackware
as time wasted *until* some one fixes the root problem - how to get a machine up
and running in 4MB.

So could we stop this 'distribution war' and concentrate on the main problem
please, rather than ranting on about irrelevent topics?

Thankyou.

(after I've found that I've got 400 mail messages in one day, with a 2MB mail
folder, consisting of ***loads*** of failed mails because system admins just
can't).
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Mon, 20 Apr 1998 18:58:45 +0100

>Someone then suggested using RedHat, and initially I didn't like it.

I remember it well.  Interesting to see how you've seen the light now. :-)

p.

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Mon, 20 Apr 1998 22:00:43 +0100 (BST)

Hi.

Maybe I ought to make my position quite clear on this subject:

1) I believe that RedHat offers the best compromise for ARM Linux.

2) The RedHat installer cannot be used on floppy to install on machines
   with 4MB of ram.  With a future PartMan, it will be possible to copy
   a small partition image into the drive, thus allowing non-floppy
   based installation.

3) If someone wants to get Slackware going, then they are welcome to
   try, but IMHO it could be effort best spent in other areas of ARM
   Linux that are more lacking.

4) The 2.1.xx kernels currently are going to require a lot of changes
   to get them to run properly on the older architectures:
   a) The MEMC is quite unlike any other memory manager in the world,
      and doesn't fit any sensible memory management model that Linux
      could provide.  Therefore, the MM is less than optimal.
   b) With the advent of ELF, and it's requirement to map the same
      data in two logical locations, this will require more
      modifications to the kernel.
   c) The large page size requires numerous modifications to the
      way memory is allocated in several parts of Linux.
   d) The kernel's malloc() routines need a hack to reduce the
      inherent overheads that it produces on large page machines.
   I'm not saying that it'll be impossible to do, but more that
   I'm beginning to wonder if the old machines are really worth the
   effort, and whether we're going to be able to continue integrating
   the architecture-specifics for these machines with obsolete
   processors into Linus' kernel source tree.

5) It is my intention to continue integrating the sources as is or as
   patches allow for these old machines.  I shall be working on this
   area, but since my resources are required for other purposes, this
   will not happen with any great speed.  If someone wishes to take
   over the kernel admin/hacking for the A5000, they are welcome.  If
   you want to know more details about this, then please mail me.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.uk.linux.org/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Mon, 20 Apr 1998 21:29:03 +0100 (BST)

> under RISCOS too, if I need to.)

Hang on a moment - RiscOS may be able to unpack tars, but can it create them?
Ok, it can create files that look like tar files, but can it handle the
unix permissions?  Can it handle the uid/gids?  I don't think so.
Therefore, to unpack a unix tar to use it on a unix system is a very
silly thing to do...

The slackware installation system uses awk, sed, strings and many others.
(Slackware 2.3 was the version that I used btw, which indeed had a broken
install).
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.uk.linux.org/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Mon, 20 Apr 1998 21:13:22 +0100 (BST)

> of completely useless info. 

That's where you're wrong.  You're talking about tar + gunzip + sh + installer.
With RedHat, you've just got the installer and cpio.  There's nothing more
to it.

> built-in tar command to unpack the slackware packages - it works great.

And if you want to teach Joe Bloggs how to use it, then go ahead.  But that's
not the end of it - it's all well untaring, but what about these installation
scripts you mentioned.  You have mentioned that you can unpack the sources,
but what about the next stage.

> I don't really think people who are smart enough to get it to even *boot*
> are going to have much trouble figuring out that the need to install perl
> before they can use a perl script. Not to forget, of course, RPM is truly
> hideous to use anyway. Trying to do anything other than one of the
> predefined action is seriously fiddly, and you don't stand much change
> of getting an RPM port to other OSs to let you modify packages before
> installing them - e.g. seperating individual files out to fit them onto
> 720K floppies.. Also - removing a package which other programs are using
> isn't smart usually - but you need to do it to make a decent job of upgrading
> versions on something. I'd much rather it just shut up and got on with it. :)

Well then, you should just make sure you use the --nodeps option everytime.
The dependencies are provided for people who may not realise the ramifications
of the action that they are about to perform.

I'd like to ask you a couple of questions at this point.  Have you tried
creating a distribution?  Have you tried making a RedHat package?

If the answer to these questions is no, then I would suggest that you try
this *before* commenting on it, since you're trying to talk about a subject
that you have only half if not less of the total facts about.

You forget, I *have* tried the tar method.  I *have* tried the RPM method.
I know what a pain the two are.  I know the problems that each one cause.
I know the benefits of each.  I know this because I have had *experience*
of them both.

As someone who has spent half a year creating the ARM Linux distribution,
I really *KNOW* how difficult it is to create a distribution.  It is not
a trivial matter, and without the RPM system, it would not be here today.
I *KNOW* where the problems lie.

Now, stop arguing about something that is IRRELLEVENT and discuss SENSIBLY
THE REAL PROBLEM AT HAND - how to get AN installer to work in 4MB, not
I DON'T LIKE REDHAT AND THATS WHY IT DOESN'T WORK.

> Linux. He's fallen in with evil companions. ;)

Not at all - he was going to use a tar file, until I explained RPMs to
him.  He immediately saw the enormous advantages that a RPM gives you
over a simple tar.gz file.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.uk.linux.org/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: David <[email-masked]>
Date: Mon, 20 Apr 1998 22:47:40 +0100 (BST)

> Therefore, to unpack a unix tar to use it on a unix system is a very

Well, I don't want to follow this too much further, but RISCOS tar *can*
create files, of sorts, but that's not the point.  (It's got lots of
really handy features too.) I can see what's in them, extract and examine
individual files and so on.  I don't loose any filenames or anything like
that because I can put them in an X-files image.  (In principle, I suppose
I ought to be able to extract to my NetBSD partitions using UnixFS, but I
haven't done it, and that might cause a problem with uid/gids - I'd have
to reset them when I next booted NetBSD.) 

David.

---

From: Alan Cox <[email-masked]>
Date: Mon, 20 Apr 1998 23:51:53 +0100 (BST)

>    a small partition image into the drive, thus allowing non-floppy

There is also the SGI and MacLinux installer work which uses libext2fs
under the native OS to unpack a base cpio for the install system
(making it do RPM is on the job list)

>       could provide.  Therefore, the MM is less than optimal.

DaveM is having a think on the diffs btw

>    processors into Linus' kernel source tree.

Rephrase that to 'who with an old ARM cares enough to fix it' ;)

Alan

---

From: Matthew Wilcox <[email-masked]>
Date: Tue, 21 Apr 1998 04:30:55 +0100 (BST)

Russell King - ARM Linux Admin
> 1) I believe that RedHat offers the best compromise for ARM Linux.

That's your belief and you're entitled to hold it.  Since you created the
distribution, others should accept that.  I still like the idea of creating
a Debian distribution, but I think that time spent working on that would
be wasted before we have libc 6.

>    a small partition image into the drive, thus allowing non-floppy

That will be really sexy.

>       could provide.  Therefore, the MM is less than optimal.

You can say that again!

>       modifications to the kernel.

I *thought* it had been agreed that that wasn't actually necessary, it was
merely the way the x86 decided to do it?

>       way memory is allocated in several parts of Linux.

Yes, I noticed that in the patches.  Are there not also issues on Alpha's
with their 8k page sizes?  I guess they tend to have so much more memory
that this is a moot point.

>    you want to know more details about this, then please mail me.

IMO, it would make more sense to separate out the port into an arm26 and
an arm32.  Yeah, I know this is a really bad time to mention it :-) Of
course, there's nothing to stop arm32 machines executing arm26 binaries.
This might encourage someone to take responsibility for the arm26 tree
off your hands.

---

From: James Craig <[email-masked]>
Date: Tue, 21 Apr 1998 09:51:52 +0100 (BST)

> (making it do RPM is on the job list)
I must admit, I'd thought about using a RISC OS application to do
something along the same lines. This would fix both the RH and Slackware
problems to the point that we could use either distribution without any
great fuss. In fact, while we're at it, .deb support would be nice too. :)
> DaveM is having a think on the diffs btw
Yeah, it's seriously weird. 32K pages are a nuisance and a half.
> Rephrase that to 'who with an old ARM cares enough to fix it' ;)
Well, I don't *have* a new ARM, so I don't have a choice in the matter -
if I want to use ARM linux at all, I need old ARM support. Guess I get to
help. Roll on the summer holidays. :)

---

From: James Craig <[email-masked]>
Date: Tue, 21 Apr 1998 10:04:34 +0100 (BST)

> be wasted before we have libc 6.
Possibly, although I'm not sure. I can't think of any reason why slackware
or Red Hat should be any different in that respect. :) 
> That will be really sexy.
Yep, very nice idea. That would solve a *lot* of problems with the setup.
> >       could provide.  Therefore, the MM is less than optimal.
Yep. :)
> merely the way the x86 decided to do it?
Likewise, but hey, I don't understand ELF all that well anyway. :)
> that this is a moot point.
Truly.
> >    processors into Linus' kernel source tree.
Leaving support for large page sizes in the kernel would be a good move,
since it increases the range of different CPUs that linux *could* be
ported to with relatively little work.
> >    you want to know more details about this, then please mail me.
I'm in no position to help at present, sadly. :(
> This might encourage someone to take responsibility for the arm26 tree
Interesting idea, but I suspect that it would lead to a complete halt on
progress on the arm26 architecture. At least with the two together, we
still get progress - if arm26 and arm32 were seperate, we'd have to update
the arm26 code seperately from the arm32 stuff, even if the changes were
applicable to both architectures.

---

From: James Craig <[email-masked]>
Date: Tue, 21 Apr 1998 10:31:35 +0100 (BST)

> With RedHat, you've just got the installer and cpio.  There's nothing more
Try ps -ax. I wish it were that simple. RH tends to run a lot of other
junk too. I admit, slackware uses a lot more seperate processes though. 
> but what about the next stage.
The total effort required to run the scripts is:
cd /mnt
.. install/install
Doesn't seem very difficult, even for Joe Bloggs. Not to forget, as I
pointed out, getting ARM Linux on a 4M machine right now is so damn
difficult, anyone even attempting it is probably going to manage that,
even if I have to write a HOWTO on it.

> creating a distribution?  Have you tried making a RedHat package?
Yes to the first. I've recompiled slackware at various points, created
slack boot disks from scratch etc. (i.e. recompiling everything that goes
on the disk, figuring out what I need on it, and putting it all together
with my own install scripts)

I've never created an RH package because I don't use RH. At all.
Whatsoever. I tried it, really didn't like it, abandoned it. I've
created debian packages in the past, although I've never actually had much
reason to use it. I know one thing - creating a slackware .tar.gz is a lot
easier than creating a RH .RPM. tar cvfz <packagename.tgz> . isn't a big
chore.

> that you have only half if not less of the total facts about.
I do know about doing this, in fact, I've even installed slackware on a 2
meg machine in the past. Having no RAM free is something I'm well used to,
and I have to distribute modified IRC servers and bots around QuakeNet
(www.quakenet.eu.org) where I'm an IRCop. Most of the other IRCops aren't
too hot at linux installation, so I need to package them in a way they can
*all* handle. RPM, they can't. .tar.gz causes no problems. 
> I know the benefits of each.  I know this because I have had *experience*
I've tried the tar method, and looked at the RPM method for about 3 hours
getting nothing but crashes, and RPM complaining about it's databases. I
gave in at that point since there's no reason for me to use a packaging
method that excludes anyone who *isn't* using Red Hat (I've tried
installing RPM on a slackware machine, and frankly, it's a pain in the
butt.)
> I *KNOW* where the problems lie.
I congratulate you on doing as well as you have. The current distribution
seems to work extremely well on machines with more than 4 meg of RAM, and
I'm quite seriously impressed with the amount of work you've put in. We
all owe you a lot for that.
> I DON'T LIKE REDHAT AND THATS WHY IT DOESN'T WORK.
I *have* been discussing this seriously. The bottom line is that on an
ix86, slackware can install on a 2 meg machine. (I can show an i386sx40
with 2 meg running Linux as proof if anyone doesn't believe me.) On an
ix86, RH can't install (easily) on less than an 8 meg machine. I think
it's fairly clear which one uses less RAM on the ix86 architecture. I know
the ARM memory management is a bit (OK, very) different, and the overheads
on processes are rather heavier, but I'd have to say the difference
between the two memory footprints is rather large.

In summary, the reason I think that a slackware distribution might be a
good thing (TM) are:

i) Slackware has a much smaller memory footprint on the ix86, which
implies that it *may* also have a smaller footprint on the ARM machines,
helping with the 4M problem.
ii) Slackware's packages can be installed manually more easily, and can be
modified on OSs other than Linux if the need arises. They can also be
split up and otherwise modified a little more readily than RPMs.
iii) A minimum slackware installation is rather smaller than a minimum Red
Hat installation. A slackware install including GCC can fit in about 20
meg (assuming you don't have the current rather huge kernel sources in
there). The last time I tried Red Hat (correct me if this figure is wrong,
I haven't used RH in quite some time) the smallest with that setup was
around the 80 meg mark.

> over a simple tar.gz file.
It *was* a joke, Russ, there's no need to be so irritable over it.

---

From: Alan Cox <[email-masked]>
Date: Tue, 21 Apr 1998 12:12:25 +0100 (BST)

> easier than creating a RH .RPM. tar cvfz <packagename.tgz> . isn't a big

cd /usr/src/redhat
rpm -ba SPECS/*

builds a full Red Hat 8)

---

From: David <[email-masked]>
Date: Tue, 21 Apr 1998 12:23:15 +0100 (BST)

> builds a full Red Hat 8)

If you happen to have "rpm" in your path.  Which I'm fairly sure I don't.
I know *exactly* where to find and how to use tar, though.

David.

---

From: Russ King <[email-masked]>
Date: Tue, 21 Apr 1998 13:49:06 +0100 (BST)

> helping with the 4M problem.

This I'd like to see - the RedHat install disk can be as small as 720k.
With the slackware install disks, I believe that they require all sorts of
binaries, which I found was extremely difficult to fit on a 1.44MB floppy
on the ARM systems, even with trying shared or static libraries.

This is more a problem on the older Archimedes machines, where you can *only*
have 720k disks.  This is where the RedHat installer has it's advantage - it
*is* smaller than the total space required by the slackware installer.

> split up and otherwise modified a little more readily than RPMs.

They can't be split up properly under RiscOS - as I'm trying to point out
elsewhere, although you *can* read tars, and *can* write tars, any attempt
to do so under a non-unix operating system will cause valuable information to
be lost.  As such, I don't see this as an issue.

> I haven't used RH in quite some time) the smallest with that setup was

The minimun RedHat install is actually 40MB, not your grossly overrated 80MB
mark.  However, rather than comparing the minimum size, we ought to be qualifing
it with what is *in* that installation.  After all, we're comparing apples and
oranges here.

> It *was* a joke, Russ, there's no need to be so irritable over it.

;)

PS, I've removed myself from the CC: line *because* I'm on the mailing list!
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]