K.Mandla's blog of Linux experiences

Build up, don’t tear down

I found a nifty link to some more speedup tips for Arch. In fact, there’s a whole thread here that talks about ways to make Arch boot in a half or a third of the time it takes normally. If you use Arch and you’re not one of those people who runs a machine 24-7, you might find them interesting.

My own speedup tips for Arch are scattered around this blog, with most of them under the Howtos page, but all of them a couple of years old already. I still use Arch, but I don’t bother tweaking it for speed any more. My philosophy toward it has changed a bit.

I left Arch for Crux when I realized I was falling into the same habit I had begun a year before, when I started carving down Ubuntu in hopes of speeding it up. The problem is that both times, my perspective was a little off-kilter.

For my own part, building a system up from scratch is always faster than tearing out parts of another one. I don’t think I’m stepping too far out on the limb when I say that; it’s common knowledge that a Linux system crafted from the ground-up is going to outperform anything that was torn down.

It’s true for Ubuntu — a command-line system with desired packages added on top is going to run faster, probably, than one that was cut down from the complete version. The same thing is true for Arch: When I started recompiling entire systems with different CFLAGS, or building custom kernels, or carving out the default init scripts, I realized that it was time to look for a different brand.

Making Ubuntu into Arch isn’t any more promising, to me, than making Arch into Crux. The work you go through trimming away at Arch is sidestepped completely with Crux, and for some people that’s ideal. It’s true, it’s the difference between an intermediate distro and an advanced one, but if you’re doing all those things in Arch, then you’re ready.

If that sounds like you, I would recommend considering something that gives you more ground-level control, in such a way that you’re not taking extra time slimming things down when you could be building up from a pure core. And if performance is your goal, then the results will be very gratifying. After all, a 16-second boot in Arch is a grand thing on a dual core, but I get those numbers from a 550Mhz Celeron, just as a matter of course.

Think about it. If you want to ask questions, there are a few of us Crux experimenters floating around here, in addition to the standard Crux IRC and mailing lists. And what we don’t know we can research together. It’s part of the learning process. 😉

Armor Nick: It did seem like overkill about a year ago, but when I realized I could do it smart and not waste an immense amount of time waiting, I realized there’s not much time lost. I keep compiled packages on hand for each system, and that way I can hopscotch up through dependencies if I find myself reinstalling something. And if I relegate my compilation times to when I’m not really using the computer — like when I’m at work or when I’m asleep — then there’s no inconvenience to me.

Of course, if you’re on a strong machine, like the one you describe, most stuff would only take a few minutes to compile. I daresay sometimes compiling it yourself might be faster than downloading a binary package if the source is slow. … 😐

I fear the Crux! Just kidding, but last time I dedicated myself to that kind of system, I was gentooing left and right, and spent too much time optimizing for that 1 or 2 second gain.

I love Arch, really do. It strikes that perfect balance, for me, especially because it isn’t hard to maintain. And after a few setups, it is especially simple to start with. I even use Arch on servers, so that says a bit.

As for the 16 second boot time, I have an EEEPC 701 which boots in 15, and that’s far from a speed demon, too; my main desktop boots in 19 seconds (probably due to peripherals) and an Advent Atom powered netbook which boots in 17 seconds, without too much hassle. Also, the biggest problem with Arch booting, the much maligned udev system which you once wrote about somewhere in here, is incredibly improved by now: I went from 7000 ms and sometimes 9000 ms to a slippery 2000 ms and sometimes less with the latest updates.

But I do get what you mean, it’s better to start lean and then add to that, than going the other way around. At least for me, with Arch I always do the inverse, I start lean and then add up, and that’s why it makes sense, TO ME. So I understand you, completely. And that’s one of the reasons I stopped using Ubuntu altogether, though I keep endorsing it whenever possible. I always ended up removing too much that I didn’t want or need, and it got worse every 6 months 😉

Onyros: I don’t know. The last time I put Arch on my 550Mhz machine was only about three weeks ago. udev times were sometimes above 20 seconds, which was completely unacceptable. And since the hardware almost never changes on those machines, scanning and rescanning the configuration every day when I turned it on … well, that was what pushed me toward Crux in the first place, so its unlikely that I’d suffer that kind of lag again unless I needed something that I just couldn’t get from Crux. But, we could say that about anything, really.

Arch is very well balanced; I will give it that. There are times when I wish I didn’t have to compile something, just to open a file or try a new program. But times like that are when I use live CDs (yay SliTaz!) and decide how badly I want to explore a new application.

K,
always impressed by what you’ll do for the speed. You get more out of a 550mhz than most do from a dual-core. My problem is that I need a security blanket. I recognize that I’m still a relative noob, but every time I get away from a Ubuntu-based distro, I find that the repositories are just not as complete (not to mention missing that incredibly active forum when I run into problems). Not advocating for Ubuntu, just curious whether you miss stuff in Crux.

It’s an interesting perspective considering moving from Arch to Crux. I know personally that I moved from Slack to Arch for ease of use on my more powerful machines. On most of my “hardware challenged” boxes I tend to still use a minimal Slack install and tend to micromanage more.