DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        b=h+ASWroF3S4pfmTjpNxzimSpnA8sfs/78z+V/k5kZVmRNf2lU/TpeGULJqgo9OHkTd
         AAnLQs5mT/OdAU8t8bNbk9X4rCzllER4XY0x2vSI1XuzzMlaCBIyKR2PZe5cBDCObYKx
         xyxPqhpx7BSpL3KJiirQTwJOu7kVqi+c+xzws=
Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= <timo.teras@gmail.com>
Message-ID: <4A702E93.4070606@iki.fi>
Date: Wed, 29 Jul 2009 14:12:19 +0300
From: =?ISO-8859-1?Q?Timo_Ter=E4s?= <timo.teras@iki.fi>
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
Precedence: list
MIME-Version: 1.0
To: Mark Constable <markc@renta.net>
CC: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] Getting started
References: <4A6F72FF.9040702@renta.net> <4A6FDA87.6090002@iki.fi> <4A702C37.2010003@renta.net>
In-Reply-To: <4A702C37.2010003@renta.net>
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable

Mark Constable wrote:
> Timo Ter=E4s wrote:
>>> Somewhere someone mentioned something about Alpine moving towards
>>> Archs' pacman/makepkg... is this true?
>>
>> When alpine 1.9 development was started one major thing to change
>> was package manager as the shell script based apk-tools was too
>> slow.
>=20
> Okay, so pre-1.9 is an ash based system? I'll have to look into
> that as I suspect most of the speed penalty is from not using
> an SQLite database for all meta-info. Just guessing.

Yes, and the fact that it had to fork/exec hundreds of times
during installation of all packages (to exec: tar, gz, various
scripts, etc. etc) and that shell scripts are interpreted.

Alpine 1.9 series has apk-tools that is generally one big
executable that forks only to execute package post/pre install
scripts. Also apk-tools link to libz and has tar parsing code,
so there's no extra penalty piping data through unix sockets.

Generally the new code always mmap()s everything and extracts
inplace, so it's pretty fast. Checksumming is done simultaneously
so the archives are read generally only once.

The new code also uses openssl for checksumming so it automatically
uses hardware acceleration if available (e.g. padlock for SHA1
stuff if openssl is patched).

>[snip]
> Right. There would be no point if the current base of Arch packages
> were not compatible and reusable. Seeing Alpine is uclibc based
> then just about all Arch packages need to be rebuilt anyway.

Correct.

> My apologies for not going through whatever mailing-list archives
> there are to research these basic points. I was in the process of
> building a busybox/uclibc/scratchbox system for Arch when I found
> out about Alpine just a few days ago.

Yeah, we should fix the mailing lists to be easer to use.

> I have some very tight guidelines for a busybox/javascript based
> desktop distro and, so far, Alpine looks much closer to where I
> want to be than Arch (which IMVHO leaves deb/rpm in the dust).

If you want anything uclibc+bb based, I suggest to seriously
consider Alpine. I've spent quite a bit of time of hunting
uclibc/bb/other related bugs. Some fixes are custom for Alpine.
E.g. uclibc has a lot of threading related things fixed.

The group is not too large, so there's no complicated politics
involved to get patches and new stuff included. But it is large
enough to get things done :)

- Timo



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---