[armedslack] Armedslack installer

Sunil Amitkumar Janki psychicistnonconformist at gmail.com
Wed Mar 28 08:24:26 UTC 2007


Stuart Winter wrote:
> At the moment I have armedslack-current reasonably up to date
> with Slackware-current.  I am currently working on building
> modular X, which is turning out to be a bit of a pain to get packaged,
> plus I haven't got X working yet either.
>   
I have already synced slackware-current so everything is already in 
place from
a source code perspective. I am glad they have already tackled the 
problem of
building modular X on Slackware Current.
> By the way - you don't need to build for armv3 if you are only intending
> on using QEMU or some new ARM hardware -- I build for armv3 because of
> a problem with the StrongARM RiscPC.
>   
I could probably build packages with ARM926EJ-S optimisations for QEMU. But
I also have a Dell Axim X3 PDA here that I would like to run Armedslack 
on. So
for now I will build armv3 packages to establish a base platform that 
benefits
as many people as possible.

The reason that I recompiled Slackware 10.1 for AMD Athlon was to see what
patches were needed to completely optimise Slackware for a specific 
processor
model on some processor architecture.

I will build optimised packages for the different targets afterwards. I 
see you
have managed to get some older software to build again. I haven't even 
managed
to get some of them optimised for AMD Athlon.

The thing I would like to see is getting all of the different Slackware 
versions for
different architectures into a single source tree. Then you would only 
have to put
something like "export ARCH=armv3", "export ARCH=x86_64", "export 
ARCH=powerpc",
"export ARCH=s390" or "export ARCH=sparc" in root's .bash_profile for each
different architecture.

> If you want to have a go at getting X working inside QEMU then that'd be
> cool.  Would it help if I just uploaded armedslack-current as is?
It would certainly help if you uploaded armedslack-current as it is now.
That would prevent me from duplicating all the work you have already done.

As far as I have seen building packages for ARM or SPARC is not really 
different from
building packages for i486 of x86_64. I only got errors on "fxload" and 
"gnuboy"
because they can only be built with 2.4 kernel headers.

By the way I have contacted Lemote (http://www.lemote.com) for a few Fu Long
test systems. These run the Godson/Loongson 2E cpu. It is a MIPS EL cpu 
running
at 660 MHz and 3 to 7 watts of power at the moment. 2F is expected to up the
speed to 1 GHz and lower the power envelope by 50%.

I intend to port Slackware to it, but that will probably take a few months.
More information can be found here: http://en.wikipedia.org/wiki/Loongson.
That will probably as near as I will ever get to a MIPS-based 
architecture because
SGI hardware is still too unaffordable and too slow for me.

It would also be great if affordable ARM Cortex based machines would become
available for the market. That would be a great platform to run 
Armedslack on.

When searching for ARM Cortex desktop I found this press release:
http://www.arm.com/news/16539.html. It says ARM platforms are even more
economical than other architectures (with the exception of Hitachi SH4).

With the release of X86_64 processors and Playstation 3 I really get a 
feeling
that x86 compatibility because of Windows is holding back the entire 
industry.

Multiplatform Linux distributions like Debian, Slackware and Gentoo could
change this.

Kind regards,
Sunil




More information about the ARMedslack mailing list