[Arm-netbook] GK802 for $70

[Tzafrir Cohen]

Hi,

On Fri, May 24, 2013 at 02:00:42PM +0300, Paul Sokolovsky wrote:
> Hello,
> 
> On Fri, 24 May 2013 12:08:25 +0200
> Tzafrir Cohen <tzafrir at cohens.org.il> wrote:
> 
> > On Fri, May 24, 2013 at 12:24:31PM +0300, Paul Sokolovsky wrote:
> > 
> > > That's not what I mean of course. There're "dedicated" package
> > > managers for embedded systems. Opkg
> > > (http://code.google.com/p/opkg/) is pretty good, as exemplified by
> > > multi-year OpenWRT experience
> > 
> > Any bug reports on dpkg and apt regarding the inefficiencies? 
> 
> In another mail I quoted couple of Ubuntu bugreports regarding dpkg
> disk thrashing on *big boxes*:
> 
> https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/580537

Duplicate of the second one.

> https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/570805

(I hope I don't confuse two or three completely separate things)

The issue came up when Ext4 was released. It seems that dpkg (as some
other programs: sqlite and Firefox^WIceweasel) was very careful about
saving the data to the disk. The changes in the semantics of fsync()
from Ext3 to Ext4 made this an issue.

One obvious workaround came in the shape of
http://packages.debian.org/eatmydata . Running:

  eatmydata apt-get install whatever

would make it run much faster, but with a greater risk to the system
status if the system was shut down in the middle. This is not much an
issue in many important cases.

However much work was put into dpkg to reduce the ammount syncing
needed.

So dpkg encountered a new environment (The new filesystem ext4 behaving
differently than ext3) and was fixed.

Can you point us to any other performance issues of apt/dpkg?

> 
> No idea about reports regarding performance on "embedded" systems,
> and just the same no idea if dpkg developers would care. dpkg
> definitely has different target usage - like doing stuff on critical IT
> infrastructure services, where you can argue for the need of
> reinsurance. Of course, ideally it should be configurable (overcautious
> vs performant), but again, who has idea if it is and how to do that? So
> all in all, besides choice "try to get dpkg right for small-perf
> systems", another one is just as valid - try something else,
> specifically optimized for performance and no-bloat.

I don't know about you, but I care very much about the integrity of my
file systems.

> 
> > It is a
> > software under active development (unlike opkg that has not seen any
> > commit since Nov-2012 and its wiki page has a number of broken links).
> 
> Eh, Nov-2012 is just half-year ago. Debian Stable ships software few
> years old as comparison. There wouldn't be a need to update package
> manager source too often - it's basic part of system and got to
> be stable. That said, opkg waits its hero who will save out of SVN into
> git.

Here's dpkg in Wheezy:
http://packages.debian.org/wheezy/dpkg

Here is its changelog:
http://ftp-master.metadata.debian.org/changelogs//main/d/dpkg/dpkg_1.16.10_changelog

Time: Fri, 08 Mar 2013 04:41:26 +0100


Here is apt in Wheezy:
http://packages.debian.org/wheezy/apt

The changelog entry:
http://ftp-master.metadata.debian.org/changelogs//main/a/apt/apt_0.9.7.8_changelog

Time: Thu, 14 Mar 2013 07:47:36 +0100


So maybe a package manager actually needs to be actively maintained?

-- 
Tzafrir Cohen         | tzafrir at jabber.org | VIM is
http://tzafrir.org.il |                    | a Mutt's
tzafrir at cohens.org.il |                    |  best
tzafrir at debian.org    |                    | friend