Arch Alternatives

phrakture · 2007-02-09 16:10:59

wuischke wrote:

Thanks to the very good layout of the /var/lib/pacman-directory this is possible using solely bash (as slow as it is) and still being faster than native code. (I claim.)

Now here is the actual original rationale for WHY the pacman DB is laid out the way it is. Text is Unix. You now have hundreds of tools available to do fancy things with pacman (awk, sed, etc etc) - though many people do not take advantage of this.

mutlu_inek · 2007-02-09 17:42:18

Snarkout wrote:

Is it actually the file itself or the inode? I thought it was the inode.

It is the inode, of course.

loserMcloser · 2007-02-10 00:39:59

Here's my favourite alternative to pacman -Ss:

1. open a web browser (don't you always have one open anyways?)
2. go to www.archlinux.org
3. use the little "Package Search" box in the upper right

Fast, and results have more information. :D

briancurtin · 2007-02-10 02:48:55

loserMcloser wrote:

Here's my favourite alternative to pacman -Ss:
1. open a web browser (don't you always have one open anyways?)
2. go to www.archlinux.org
3. use the little "Package Search" box in the upper right
Fast, and results have more information. :D

ive never actually used pacman -Ss in just over a year of Arch use, outside of seeing the time for this thread. i always search on site since i always have a browser open when i want to install something

deficite · 2007-02-10 06:34:13

loserMcloser wrote:

Here's my favourite alternative to pacman -Ss:
1. open a web browser (don't you always have one open anyways?)
2. go to www.archlinux.org
3. use the little "Package Search" box in the upper right
Fast, and results have more information. :D

Sorry, but even when using just plain old "-S" one still has to wait.

Last edited by deficite (2007-02-10 06:34:26)

buddabrod · 2007-02-25 20:12:12

time pacman -Ss pacman
current/pacman 2.9.8-4
    A .tar.gz based package manager with dependency support
extra/namcap 1.5.4-1
    A Pacman package analyzer
extra/srcpac 0.4.1-1
    The pacman from-source wrapper
community/jacman 0.4-2
    Java-based GUI front-end for pacman
community/kpacman 0.3.2-5
    The classic pacman arcade game for the KDE Desktop

real    0m1.054s
user    0m0.608s
sys     0m0.284s

On jfs here. Maybe some of you should check fragmentation on your disk

soloport · 2007-02-26 22:31:17

deficite wrote:

Sorry, but even when using just plain old "-S" one still has to wait.

That's because -S is for *large* seconds (thus the wait). When you use -Ss, it's in-between slow. Try using -s for much smaller (faster) seconds. Makes a big difference.

Seriously, how did we get from "recommended distro?" to this?

And to get back on topic. I'd highly recommend Fedora 6. Haven't used anything from Red Hat for years, myself. But if you're going to go all soft over a thing like "slow pacman", then I say you really need a little reminder or two... oh. I see how we got here now...
.

Last edited by soloport (2007-02-26 22:35:43)

F · 2007-02-27 00:39:57

soloport wrote:

Seriously, how did we get from "recommended distro?" to this?
And to get back on topic. I'd highly recommend Fedora 6. Haven't used anything from Red Hat for years, myself. But if you're going to go all soft over a thing like "slow pacman", then I say you really need a little reminder or two... oh. I see how we got here now...

Some people seem to have issues with pacman, thats how. However nobody seems to know what the hell is going on because it works perfectly fine (and fast) on 90% of all other users.

Kern · 2007-02-27 00:41:06

Seem to remember pacman slowing down quite a lot over time, despite optimizing it.
Trusting the devs more than myself i put it down to my lack of *nix experience, rather than it being pacmans "fault".
pacman offered so much in the way of advantage and versatility, i really didnt see the slowdown as being that important.

anyways, recently swapped to new drive, reinstalled (what a joy with 0.8 thanks to ppl like tpowa et al) and hey presto, pacman is like sh*t from a teflon shovel.

time pacman -Ss pacman
real 0m0.346s (upto 0.457 on repeats)
user 0m0.160s
sys 0m0.152s

So probably the slowdown was the spread of files, rather than any inherent fault. the wait time was between pacman -Ss foobar, the hard drive thrashing and it returning the results.

Not tried Cage yet, but from what i read it seems an ideal solution to put all the pacman cache / whatever into a small contiguous space.

maybe for those that cant just find the perfect distro for themselves as most distros have some kind of perceived drawback, try LFS

Edit: pacman timings added. will post old drive timings, for comparison, when i plug it in again.

Edit2:
ok senility has set in. must have been my other older Pc (athlon 2200) too that was even more lethargic.

old drive in current system
real 0m14.370s
user 0m0.216s
sys 0m0.308s

old drive in current system after pacman-optimize
real 0m0.455s
user 0m0.180s
sys 0m0.216s

current proc AMD Athlon 64 3500+

one thing it highlights tho, its not all down to hard drive speed as someone above hinted at.
the ones on the new system are from a seagate 18GB SCSI 15,000 rpm.
the old drive in Edit 2 is hitachi 250Gb ide 7200 rpm. not a great difference is it?

Last edited by Kern (2007-02-27 01:28:59)

geek.arnuld · 2007-06-07 19:57:25

onearm wrote:

No problem here, ext3 using dir_index:
time pacman -Ss pacman

real    0m0.584s
user    0m0.297s
sys    0m0.281s

well, i have an 80GB ATA. using ext3 tips from here: http://forums.gentoo.org/viewtopic-t-30 … +tips.html

i have "journal_data" and "dir_index" enabled and this is the result:

[arnuld@arch ~]$ time pacman -Ss pacman
real 0m0.289s
user 0m0.152s
sys 0m0.140s
[arnuld@arch ~]$

onearm wrote:

Before I was using Xfs for /var and that was really slow (I mean even after pacman-optimize and removing all the cache)

XFS literally killed my hard disk with long...NO......very-long.. seek times. i tried XFS on my Serial-ATA i had earlier. much worse experience. "ext3" with above tips applied is great :-)

lilsirecho · 2007-06-07 20:30:15

Another OS to try! Faunos booted to ram may produce faster pacman performance. Try it!

STiAT · 2007-06-07 21:29:23

I've had this problem on ext3 as well on my core duo 2 (so a quite fast) system. It took pacman almost 2 minutes for a -Ss operation.

Anyway - did i fix it? Indeed. I used the way iphitus suggested. I've placed the pacman databased on a own filesystem. I just made two partitoins, one is now just for pacman (/var/lib/pacman) the other one is the /var filesystem.

Since this, pacman (after a fresh boot) needs ~4 secs for pacman -Ss.
The nice thing is, if this comes up again (or similar), even when the partiton is smaller, you can jus re-creae the filesystem and copy the pacman files there again.
Works nice. Maybe it should be an option for a "default" install providing a own partition for /var/lib/pacman.

Yours,
Georg

lilsirecho · 2007-06-07 21:44:44

My speed in faunOS....

real 0m0.013s
user 0m0.008s
sys 0m0.004s

johnisevil · 2007-06-08 03:06:27

Here's my contribution to the thread.

john@metatron: ~ >> time pacman -Ss pacman

real    0m0.616s
user    0m0.346s
sys    0m0.260s

This is on first run after a fresh reboot. I use the setup found here. I have 0 speed issues with pacman.

Last edited by johnisevil (2007-06-08 03:07:06)

aris002 · 2007-06-08 12:21:05

As I understand, this topic better should have been named: "I don't like Arch - how to optimize pacman?"
But - big thanks for it! Arch is my the first and the only one for quite a while... and only now I have discovered - pacman can run ~7!!! times faster just with:

$pacman-optimize

The result :

real    0m1.341s  (second run) - first run was ~0m4.???s (before optimization - 7s and 15s!)
user    0m0.205s
sys     0m0.409s

not bad for a quite old laptop hdd, reiserfs and huge amount of arch, other users and my own repos...
The best things about Arch:
1. Fastest.
2. Simple.
3. Hot rolling releases from the kitchen! (Thanks to all devs and contributors)
4. ABS (Gentoo-like?).

Alternatives - MacOS. And other distros (my - Fedora, Suse still waiting) on Parallels! And most likely you you'll come back after some time... because... of pacman!

Leigh · 2007-06-08 12:57:58

Recently I was given a 250g usb hd to play with. I decided to use most of it for storage and 50g for a back up install. I started hopping from distro to distro to check them out. Some I liked, and some I didn't, but none came close to what I like about arch. Maybe it's just because I'm so use to arch, but arch's install is just so straight forward and easy! I think even a linux novice wouldn't have any trouble installing arch, except maybe for editing the confg files. Even so, the installer had all the right settings in the files to at least successfully boot arch. I think it took me all of 15 mins to go from inserting the base ftp install disk to being booted into my new usb base install. Anyway, after playing with some distros like frugalware, vector, slackware, and even messed around with pc-bsd for a bit, I came to appreciate arch that much more! I finally settled on a 2nd install of arch to use as my back up install, which makes better sense as I can test packages that might be unstable without any worries.

Just want to say to all you arch maintainers, you guys are the bomb! Thanks for keeping Arch so kicks ass! : )

beissemj · 2007-06-19 05:34:52

soloport wrote:

And to get back on topic. I'd highly recommend Fedora 6. Haven't used anything from Red Hat for years, myself. But if you're going to go all soft over a thing like "slow pacman", then I say you really need a little reminder or two...

No kidding man. YUM is ridiculous... you want to see slow, omg.

On the other hand, Package management is one of the most important things in a distro, imho. It's why I switched from, Gentoo -> Debian -> Fedora -> Arch. That being said I don't think their is any 'perfect' solution. Each system has it's fault. It's just a matter of which are acceptable to you. For instance...

Gentoo - Compiling every single thing on your system is ridiculous.
Debian - apt-get is stupid sometimes, and foo-barred my system more than once.
Fedora - Yellow Dog Update manager (aka YUM), well grass grows faster
Pacman - Cache needs to be updated every so often.

So I guess it's just in what you want. Since you are using Arch you have to consider the trade offs. Yes package searching might be slow at first, but you have to weigh that against certain aspects of other distro's. (For example, do you a slower package search [Arch] or a faster search and more bloat [Ubuntu]).

Besides, Arch has gotta be bad in something. We have to let the competition win sometimes

Last edited by beissemj (2007-06-19 05:36:06)

Arch Linux

#51 2007-02-09 16:10:59

Re: Arch Alternatives

#52 2007-02-09 17:42:18

Re: Arch Alternatives

#53 2007-02-10 00:39:59

Re: Arch Alternatives

#54 2007-02-10 02:48:55

Re: Arch Alternatives

#55 2007-02-10 06:34:13

Re: Arch Alternatives

#56 2007-02-25 20:12:12

Re: Arch Alternatives

#57 2007-02-26 22:31:17

Re: Arch Alternatives

#58 2007-02-27 00:39:57

Re: Arch Alternatives

#59 2007-02-27 00:41:06

Re: Arch Alternatives

#60 2007-06-07 19:57:25

Re: Arch Alternatives

#61 2007-06-07 20:30:15

Re: Arch Alternatives

#62 2007-06-07 21:29:23

Re: Arch Alternatives

#63 2007-06-07 21:44:44

Re: Arch Alternatives

#64 2007-06-08 03:06:27

Re: Arch Alternatives

#65 2007-06-08 12:21:05

Re: Arch Alternatives

#66 2007-06-08 12:57:58

Re: Arch Alternatives

#67 2007-06-19 05:34:52

Re: Arch Alternatives

Board footer