Subject: ARMlinux vs. RiscBSD

From: "I.V.McLoughlin" <[email-masked]>
Date: Sat, 10 Jan 1998 12:51:57 +0000

Hi,

I don't mean to be contravercial-my question is a serious
one.

I'm a user of Solaris (on Suns) , RiscBSD (on my RPC)
and Linux (only on PC atm).

RiscBSD is a great product and works well on my SA-RPC,
but I really need to know how this compares against
ARM Linux.

Is there anybody that has used both RiscBSD 1.3 and a
current version of ARM Linux: what features do both have
do they lack any features.

Some questions in particular - can ARM Linux users access
the ADFS hard discs from within Linux, and can they read/write
the Linux partition from ADFS too?

Which is a more 'efficient' implementation? Does ARM Linux
use shared libraries?  Is it a stable platform for commercial
code development?

I think we're lucky to have multiple UNIX versions available
for our Acorns - and I congratulate the developers who've made
this possible.  Multiple versions give the user more choice 
and bring Acorns out more into the 'real world of computing'.
But it does make the choice a little complicated from the users
point of view, so any help that people can give me will be
appreciated. Perhaps off-list replies would be better unless
others also require this information.

tia,
Ian McLoughlin
--
Dr. I.V.McLoughlin   [for Chinese, S.E.Asia, Speech & DSP]
|_ School of Electronic and Electrical Engineering,
|  The University of Birmingham, Edgbaston, Birmingham.
|_ Simoco Telecommunications Ltd., Cambridge
|_ http://sun1.bham.ac.uk/i.v.mcloughlin
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Matthew Wilcox <[email-masked]>
Date: Sun, 11 Jan 1998 01:38:12 +0000 (GMT)

> I don't mean to be contravercial-my question is a serious

Understood.  Bear in mind that any reply you get is liable to be
ill-informed, and/or based upon the prejudices of the respondent.
I do not except myself from this.

> but I really need to know how this compares against

RiscBSD is somewhat more mature than ARMLinux.  This means it has a
greater installed base of users and supports more hardware.  Against that,
there's vastly more software available specifically for Linux than NetBSD.
Personally, I deplore this, but that's the way of life it seems ;-(

> the Linux partition from ADFS too?

The ADFS hard disc is readable, but not writable.  This isn't something
that's fundamentally missing, it's simply that no-one's implemented it
yet.
Thanks to Forrey (Phil Norman), there's an ext2 partition reader for
RISC OS, but again it's not writable.  It's also not a proper filing
system, it's very much like SparkPlug.

> use shared libraries?  Is it a stable platform for commercial

ARM Linux has better performance, I've been told.  Yes, ARMLinux has shared
libraries, but they're based around the libc4.  Until we have ELF, we cannot
migrate to libc6.  Work is in progress on this.  There are a few problems
with libc4 that I simply haven't bothered to trace, because they will go
away when libc 6 is introduced.

I'd call it stable.  It's frozen solid on me once in the last week, and
I don't exactly treat it gently.

---

From: "Neil A. Carson" <[email-masked]>
Date: Sun, 11 Jan 1998 02:28:43 +0000

> I do not except myself from this.

Neither do I :-) but I try my best.

> Personally, I deplore this, but that's the way of life it seems ;-(

I wouldn't agree with this; any changes in software compiling that need
to be made are normally because of the ARM, not because of the host OS.
IN a similar vein to all the Linux distributions, there are all the
NetBSD 'packages' (around two gigabytes of source) that build straight
away. In any case, we'll be seeing StarOffice for NetBSD/arm32 as and
when StarDivision finish it off :-) and maybe also Netscape when the
Communicator port is finished (Nav 3 attempt failed, but the
Communicator licencing is different).

> system, it's very much like SparkPlug.

Yep, on RiscBSD there's no way of getting at the ADFS partition from
inside it (although someone has written such a utility) but you do have
the full read/write from RiscOS.

> away when libc 6 is introduced.

ARM Linux forks quite a bit faster than RiscBSD (about 10X :-) ). This
is because the Mach VM in RiscBSD was written completely without virtual
split caches in mind. Other than that, performance is pretty much the
same---both systems being hit by the context switch time on StrongARM
which figures largely in 'internal latency' benchmarks. RiscBSD's shared
library system is better, not requiring fixed addresses and using PIC
code instead (which can occasionally cause problems compiling programs
without support for the older Linux library model).

Well I think I've tried to be unbiased :-)

	Regards,

	Neil

---

From: Matthew Wilcox <[email-masked]>
Date: Sun, 11 Jan 1998 03:23:05 +0000 (GMT)

> to be made are normally because of the ARM, not because of the host OS.

Possibly.  I've certainly seen a lot of problems with programs assuming
signed chars.  Since both ports use GCC, and gcc plain chars default to
unsigned on the ARM (for efficiency reasons), this causes programs to not
compile out of the box on either OS.

The most common example I've seen of this in Linux utilities is comparing
the `int' return from getopt to a variable of type `char'.  If you ever
see a warning about comparison always being 0 or 1 due to limited range of
data type, suspect this sort of problem and investigate.

> Communicator licencing is different).

Hmm.  Anyone fancy writing aBCS?  Or forming a working committee to
discuss an arm-open binary standard?  ;-)

> which figures largely in 'internal latency' benchmarks.

According to a friend who's run 2 ARM610 RiscPCs side by side, ARMLinux
feels more responsive in practice.

> RiscBSD's shared

I agree.  The RiscBSD 1.3 library system is definitely superior to the
current a.out based ARM Linux system.  However, once ELF happens and we
move to glibc, I believe the Linux system to be superior.  I have to
admit that's more a gut feeling that 100% based on experiment ;-)

> Well I think I've tried to be unbiased :-)

Except you didn't include your sig declaring you work for Causality ;-)

(though you'd've had to have your head under a rock for the past 2 years
to not realise Neil was an original memeber of the RiscBSD project ;-)
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: "Neil A. Carson" <[email-masked]>
Date: Sun, 11 Jan 1998 04:55:59 +0000

> discuss an arm-open binary standard?  ;-)

:-)

> feels more responsive in practice.

You noticed I wrote 10X not 10%. Binaries will run at the same speed on
both, but Linux will load stuff a damn site quicker and also handle
processes that fork better (eg PostGres server forks on each new
connection, though we are working with a VM guy to try and fix this). In
general this adds to the feel of responsiveness of the system, making
Linux much more 'snappy.' Some things will detract---RiscBSD's Floating
Point is several times faster than Linux's for example, but I think
overall Linux is reckoned to be more responsive when running stuff. I
think in X with some programs already running you'd be hard pushed to
notice any difference.

Also, one has to consider scalability in these things---whereas under
light load a Linux system will often outperform most other counterparts,
certain areas of eg the VM system will scale with L^2 in terms of their
efficiency (where L is the load on the system for example) whereas on
*BSD this often tends to be a flatter (though still not completely
linear, obviously), more proportional relationship. This is why FreeBSD
and NetBSD tend to be very popular in heavy server applications, but
less in workstation applications. Though FreeBSD offers similar figures
to Linux at the lower end as well :) offering stuff like kernel threads
that RiscBSD currently lacks.

> admit that's more a gut feeling that 100% based on experiment ;-)

ELF eases stuff like C++ debugging, and when gcc 2.8 makes it I believe
will offer significant advantages. We've done most of the stuff to make
ELF possible in our a.out-PIC stuff, but we thought we'd wait on you
chaps to do the last leg :-) The main thing for us was to get a proper
mechanism going with the current toolchain (as NetBSD never supported
the fixed address stuff) but we stopped there because of other
committments. So Linux will have a definate lead on this until we catch
up.

> to not realise Neil was an original memeber of the RiscBSD project ;-)

Indeed! Just over three years in fact, how time flies :-) Though I try
to think I can speak about these things with my head screwed on properly
and without bias: I have ARM Linux installed myself (though I prefer to
use VMS than any UNIX anyway, OK go on laugh :) ) and have used it for
some stuff, and it is more snappy. Really it's horses for courses, as I
said in a recent article on the two OSs.

If you want solidity, filesystem reliability, fast FP, a fully working
toolchain/C++ (yes I know we broke C++ recently, but a fix is going out
now!), easiy install etc go for RiscBSD. If you want something that runs
as fast as possible, has the lowest memory requirements, and is more
popular/funky, choose ARMLinux. If you want both, buy a PC and put
FreeBSD on it :-)

	Regards,

	Neil

---

From: Sergio Monesi <[email-masked]>
Date: Sun, 11 Jan 1998 12:00:48 +0100

In message <[email-masked]>
          "Neil A. Carson" <[email-masked]> wrote:

> Linux much more 'snappy.' 

Apart from this fork problem (try to run "find -exec grep" or something
similar on RiscBSD!), RiscBSD's disc caching seems to be far inferior
compared to ARMLinux and, actually, it doesn't seem to work at all on my
machine (24Mb DRAM)!

In fact, the second time I run, say, "ls -lR" (or even something more complex
with some pipe) on Linux I got an instant output and no disc access while
there is no noticeable difference between the first and second run of that on
RiscBSD.

Maybe I should configure more buffers (I think it is possible to do this from
the bootloader) but I suppose that Linux uses a dynamically resizeable buffer
area...

Also, I got no problems connecting to Internet using PPP on ARMLinux but I
remember that I had many problems with RiscBSD when I tried ages ago (1.1
release probably).

> I think in X with some programs already running you'd be hard pushed to
> notice any difference.

"find / -exec grep ..." in an Xterm? :-)

> If you want [...] a fully working toolchain/C++ [...] go for RiscBSD. 

I tried to compile Lesstif and Afterstep on ARMLinux without much success
(especially with the former). I don't know if these work as expected on
RiscBSD...

About 'solidity' and 'filesystem reliability', I wouldn't say this for
RiscBSD, last time I tried it with 12Mb of RAM many programs crashed (eg.
gcc, X) due to incorrect handling of many page faults and sometimes the
kernel crashed as well. This doesn't seem to happen with more memory but I
wouldn't rate the system as 'stable' with such a bug in the kernel... Please
correct me if I am wrong and this has been fixed recently!
I never tried ARMLinux with 12Mb of RAM so I can't comment on it...

Sergio

-- 
Sergio Monesi...         \ . . . \  Cracking RC5-64 with a StrongARM RiscPC
mailto:[email-masked]     \ . . . \  http://rc5.distributed.net/
http://bounce.to/sergio/   \ . . . \  Join the Wild Wereboar Team (#1308)!

---

From: "Neil A. Carson" <[email-masked]>
Date: Mon, 12 Jan 1998 06:10:03 +0000

> there is no noticeable difference between the first and second run of that on

There wouldn't be. As I've said before, these things aren't clean+dry
that simple---it's different philosophies behind the OSs. What happens,
is that the FFS filesystem synchronously writes through critical
meta-data to the filesystem in order to help guarantee a consistent
state in case the FS crashes due to power failure. This makes the system
more robust, but slower on certain operations (opening, closing,
creating and deleting a file---reads and writes of data will be the
same).

Changing allocated buffers won't help. What you really want, again, is
FreeBSDs new IOVM system :)

> remember that I had many problems with RiscBSD when I tried ages ago (1.1

1.1 is ages old, to be fair. ppp works perfectly fine with RiscBSD, and
many users have modems connected with it.

:-)

> (especially with the former). I don't know if these work as expected on

Lesstif (also QT, KDE etc) certainly do, I haven't tried afterstep.

There shouldn't be a problem running with 12MB RAM, and the X server is
pretty stable these days and supports several different bpps---and
things like font realisation are much faster because of the much better
FP capability.

What really matters is not "what knocks what on what," but really the
differing philosophies and planned uses of the OSs. I've never been a
great fan of OS advocacy (apart from the BeOS!), certainly not as
regards UNIXs anyway. My advice is for a single user meddling system run
Linux, for a file server run RiscBSD, and for the best of all worlds use
FreeBSD on a PC.

	Regards,

	Neil

---

From: Alan Cox <[email-masked]>
Date: Mon, 12 Jan 1998 09:35:04 +0000 (GMT)

> creating and deleting a file---reads and writes of data will be the

Actually there are fairly comprehensive proofs that synchronous metadata
increases the probability of corruption because it produces cases where the
metadata (ie the file system structure) is correct but the data within the
files was never written.

What we both want is a logging ext2/ufs. As far as I am aware both are in
progress. Its one of the important items for an embedded system unless you
want to include a UPS instead ;)

Alan

---

From: Charles Esson <[email-masked]>
Date: Mon, 12 Jan 1998 09:27:46 -0500

> metadata (ie the file system structure) is correct but the data within the

Dam right, a correct directory might be nice for the kernel but it is of little
use to the application, if the data is rubbish.

The big differences are:
1) The license terms, read both carefully if you want to use it for commercial
purposes, and pick the one you prefer. Your choice.
2) The standard the systems are based on, I think this is of little relevance
but some might think otherwise. Your prejudice
3) Popularity of linux and riskBSD in general. Do a web search to form your own
opinion.
4) Development activity. I think riskBSD were the winner, but I could be wrong,
I think linux is catching up, now if Causality where to swap to Linux.

Me I picked linux, given time I think the ARM version will catch up to RiscBSD,
and there is a greater chance the people I hire and the customers I sell to
will of heard of it.

It was not a technical choice, technicaly I don't like unix or its derivatives
for real time control.

---

From: Alan Cox <[email-masked]>
Date: Mon, 12 Jan 1998 14:54:55 +0000 (GMT)

> It was not a technical choice, technicaly I don't like unix or its derivatives

Just out of curiousity have you ever looked at the RTLinux work at NMT,
putting Linux (or in theory any other OS if tweaked) on top of a very small
hard real time kernel.

It runs hard real time tasks in the RT kernel and they can talk via queues
etc to the non hard RT Unix on top of it

Alan

---

From: Sergio Monesi <[email-masked]>
Date: Mon, 12 Jan 1998 12:01:18 +0100

I'm sorry if I seemed to criticize RiscBSD without knowing what I was
speaking about... 

However, I think that most Acorn users prefers to have a UNIX tuned for a
low-level workstation, not for a top-level server which the RiscPC obviously
isn't, so Linux seems to be the right OS for us...

In message <[email-masked]>
          "Neil A. Carson" <[email-masked]> wrote:

> Sergio Monesi wrote:
> > In fact, the second time I run, say, "ls -lR" (or even something more
> > complex with some pipe) on Linux I got an instant output and no disc
> > access while there is no noticeable difference between the first and
> > second run of that on RiscBSD.

OK, I understand this, but where are the write/create/delete operations in
"ls -lR"? I can't see any risk in buffering the data used by "ls -lR",
whatever happens during its execution, the filesystem integrity cannot be
compromised.

Incidentally, the slowness of the RiscPC internal IDE impacts heavily on
RiscBSD, let alone the SCSI drivers that seems to be terribly slow (from what
I read on the mailing list)... How do you hope to use RiscBSD as a file
server?

> FreeBSDs new IOVM system :)

Since you seem to appreciate almost every feature of FreeBSD, why didn't you
(actually the RiscBSD kernel team) port it instead of NetBSD? Would it be
hard to switch to FreeBSD now? What about porting to NetBSD all those nice
peculiarities of FreeBSD?

Cheers,
Sergio

---

From: "Neil A. Carson" <[email-masked]>
Date: Mon, 12 Jan 1998 18:32:58 +0000

> metadata (ie the file system structure) is correct but the data within the

I think it's swings and roundabouts: McKusick (author of original FFS)
is presently licencing some pretty cunning buffer cache code, which
constructs a directed graph of the synchronous dependencies in the
buffer cache, coalescing this ordering where possible and then doing the
writes in order where required. He's currently making a bomb off this
(it's pretty complex apparently), licencing it to Sun, companies with
big servers, and such folks---there's clearly plenty of evidence to
prove the opposite too which is of course why the thing was written that
way in the first instance. So there's clearly a lot of people out there
who've proven these proofs otherwise.

I wouldn't have thought the chance of corruption would go up, because
the filesystem will still be dirty anyway so stuff would be constructed
automatically upon fsck. What I believe is that it reduces the
likelyhood of manual intervention being required at fsck time (ie major
inconsistencies that are not automatically solvable, rather than more
minor ones) so that more files tend to be lost+founded or i-nodes
cleared.

> want to include a UPS instead ;)

When I've finished some stuff, I was going to write a journaling
any-UNIX filesystem providing some features similar to SGIs xfs (if
someone is also doing this now, let me know to save me wasting my effort
later on :) ).

Some recent research into log-structured filesystems (I believe there
was a Linux log-structured project) by the FreeBSD guys---as they've
finally got one of them working at last :) --- have suggested that these
are in fact a waste of time compared to McKusicks funky stuff, apart
from the decreased fsck time of course.

Well, all interesting stuff :-) though I'll shut up as filesystem design
is probably not a topic for this list!

	Cheers,

	Neil

---

From: "Neil A. Carson" <[email-masked]>
Date: Mon, 12 Jan 1998 18:36:44 +0000

> I think linux is catching up, now if Causality where to swap to Linux.

We tend to be quite agnostic about stuff I think---well I try anyway. I
use loads of different OSs on a regular basis, all of which have merits
and problems. If we were starting again now (we've been developing 'BSD
for over 3.5 years now, after all :) ) we'd probably have chosen Linux,
but at the time it was completely unportable which stopped us. If we
were starting again in another three months time, we'd probably choose
FreeBSD, as the current state of FreeBSD-current has one of the most
advanced VMs (which will work extremely well with ARM) of any free OS.
In a similar light, though, we find ourselves doing stuff with CPUs
other than ARMs now, so the ARM is not 100% priority---more 75% and
falling :-(

	Cheers,

	Neil

---

From: Charles Esson <[email-masked]>
Date: Mon, 12 Jan 1998 13:48:19 -0500

Alan Cox wrote:

> etc to the non hard RT Unix on top of it.

No I havn't I will take a look at it. Thanks.

---

From: "Neil A. Carson" <[email-masked]>
Date: Mon, 12 Jan 1998 19:32:51 +0000

> isn't, so Linux seems to be the right OS for us...

In the majority of cases, I'd agree with that!

> whatever happens during its execution, the filesystem integrity cannot be

It's the update of the inode-last-accessed times. Strictly this doesn't
need to be done sychronously, but if you don't it creates problems when
trying to do other things synchronously, so... There is an asynchronous
mount option, which is nearly fully implemented now, which can (shortly)
be used instead.

> I read on the mailing list)... How do you hope to use RiscBSD as a file

RapIDE :) A lot of companies use a machine in this config for serving
smallish networks of NCs (including Xemplar's standard small-network
solutions, Acorn's clients etc) and, because most serving doesn't
involve forking, it does pretty well.

> peculiarities of FreeBSD?

FreeBSD would involve a fair bit of work, but it's being considered.
Really FreeBSD has next to no BSD left in it anymore :-) Again initally
it was unportable, like Linux---the main reason that we did NetBSD was
it was the only portable OS at the time, and even now it still tends to
be easier to maintain architecture ports than other free OSs.

	N.

---

From: Alan Cox <[email-masked]>
Date: Mon, 12 Jan 1998 20:02:51 +0000 (GMT)

> automatically upon fsck. What I believe is that it reduces the

What occurs is that the Linux case you lose the last few writes, the BSD 
case you lose the last few data writes

> minor ones) so that more files tend to be lost+founded or i-nodes

Actually that isnt the case. It requires your fsck is a fraction smarter
but not significantly. The main issue is deleted files.

> was a Linux log-structured project) by the FreeBSD guys---as they've

Yep. And theres also a journalled ext2fs project which is fairly
similar to McKusicks work but a lot simpler in its approach. (NTfs btw
is very similar in its algorithms to McKusicks work)

> from the decreased fsck time of course.

For ARM stuff the important thing to most folks is that if you flip the
switch you cannto damage any data.

Alan

---

From: "Neil A. Carson" <[email-masked]>
Date: Mon, 12 Jan 1998 23:09:32 +0000

> is very similar in its algorithms to McKusicks work)

NTFS? As in the filesystem for Windows NT? That uses a Journal for
preserving the synchronous nature of its operations. Of course the
journaled ext2 will be slower than the current one---about half way
between the speed of FFS and the existing ext2, but with much greater
reliability and fsck times than either. Hmm I wonder if you could do
what McKusick does, and splat out the directed partial ordering to disc
just before doing most of the ops, thus gaining most of the speed of
ext2 and the reliabiltity of 
a journaled FS? Food for thought :-)

Is there a URL for the journaled ext2FS project? I'd quite like to do
some porting over of this as/when it's nearing completion.

	Regards,

	Neil