one: Another attempt at unification

Odd that one would come up in the rotation today, but I’m comfortable with that. If you remember kkm or wajig, you might appreciate what one hopes to accomplish — solidify the package management task in Debian to a single command. 😯

I don’t have a screenshot for you, because I suspect a successful screenshot of one would show … dpkg or aptitude or apt-get or apt-cache or what have you, doing what it usually does. Terrifically uninteresting.

one defaults to installing a package, meaning just one rsync should pull down rsync and install it. Simple enough.

After that, the default commands become one- or two- (or sometimes three-) letter mnemonics for whatever procedure you’re trying to accomplish. Ergo, s for search, i for details (or info), o for ownership, and so on.

Personally I have no compunction about using a tool like one, or wajig or kkm, to be clear. I occasionally find myself frustrated by having five or six separate tools available on a Debian system, when there is just pacman on my other computers.

I leave it to you to decide if something like one (or kkm or wajig, of course) is a good thing or a bad thing for the overall Debian structure. I am content to rely on Debian as a solid foundation distro, and permit each user the leeway to use unifying tools as they see fit.

And in case you’re keeping count, there are almost as many unification efforts now as there are tools to unify on a Debian system. How’s that for irony? 😆

wajig: Unite the clans!

Back to Linux Mint for this one. If you’re not using something Debian-ish, it probably won’t work for you … let alone appeal to you.

I haven’t been shy in the past, in critiquing Debian’s rather scattered approach to package handling. Between dpkg, apt-get, aptitude and apt-cache, with the added complications of things like debsums, deborphan and host of other tools, things get a little frazzled.

I understand most of the fragmented structure and the reasons for it, but I can also tell you that comparing those dozen programs to pacman is night-and-day.

If I had to pick a single tool to unify them, wajig would be my weapon of choice. wajig — look here if you have to know about the name right now — consolidates most of the tools I’ve already mentioned, and collates their individual commands into a master list.

Don’t worry, you don’t have to relearn new commands; most are grandfathered into wajig. So apt-get install appears as wajig install, and apt-cache search appears as wajig search. Convenient.

wajig also liases with some ancillary programs like deborphans and debsums, as I mentioned above. Remember if you want to take advantage of those features in wajig, you’ll need to install the programs that actually do those chores. wajig doesn’t doesn’t reinvent the wheel, it just makes it easier to spin it.

wajig does a few other things right — like an onboard tutorial, or a full list of commands and their descriptions. No color, but you can’t have everything.

If you’re serious about Debian and you frown on things that tamper with the delicate default ecosystem, then perhaps wajig isn’t for you. On the other hand, if you’ve stepped outside that walled garden and seen, for example, how Arch does things, wajig might be a much more appealing way to do business.

Just for my own part, I expect I’ll be installing it on the next Debian-based machine I build. I’m not so much a purist as to turn my nose up at convenience. … 😉

sysv-rc-conf: Going, going, gone

Back in March rcconf came up, and with it the question of whether that, or for that matter this, will really be of much use in the future.

That’s sysv-rc-conf, from the XFCE version of Linux Mint. As it is — or maybe, as it was — you can navigate with the arrow keys, and enable or disable a service with the space bar. Very straightforward.

Long time ago sysv-rc-conf was a fairly effective way to cut back on the dreck that was installed by default in Ubuntu and its cousins. Reduce the unnecessary startup programs, reduce the startup time. Scoff if you like, but in 2006 and at 300Mhz, there was a big difference.

Of course now, a 300Mhz machine is a rarity, and even if you had one, installing Ubuntu on it would be a crime against technology. sysv-rc-conf or no, unless you’re running pure Debian, I don’t think it will make a lick of difference.

And of course, the impending shift to systemd makes things even murkier. I don’t know if there will be an analogue to sysv-rc-conf under systemd, but my gut says no.

So enjoy it while it lasts. Drag that old Pentium II out of the closet, put the Debian LXDE desktop on it, fire up sysv-rc-conf one last time and see how much closer you can get to a single-digit startup time.

It’s the way of the world, friends: Modern becomes obsolete, obsolete comes classic, classic becomes vintage, and vintage becomes artifact. Boats against the current, borne back ceaselessly into the past.

rcconf: Enjoying the nostalgia

I’m going to mention rcconf today, even though I have my doubts about its viability in the future, given the decision to switch to systemd. Here it is on Mint, just the same.

rcconf reminds me of the good old days when I was hell-bent on eking every gram of speed out of the Golden Age of Ubuntu. (Yes, I refer to pre-2010 Ubuntu releases as its “Golden Age.” Get used to it. 👿 )

In short, this is a text-only interface to manage runlevels on a Debian-based machine. As you can see above, there are quite a few at work on a default installation.

In theory, disabling a few of these should result in a perkier system. The underlying theory being, the less extraneous services, the less time the processor spends skipping over the clutter of unused processes. Add them all up and they might make a difference to you.

All that is strictly theory from my perspective though. And given that machines these days barely lose any time to teeny unused processes, it might not make a difference at all.

On the other hand, if you’re working with the hardware of the last decade, you’ll probably want to give this a chance.

For what it’s worth, it’s important to make a distinction between Debian’s rcconf and sysv-rc-conf. One manages runlevels and one the SysV startup; I’ll gloss over sysv-rc-conf in the S section.

About two years from now, probably. 😯 🙄

P.S.: If you’re an Arch user and you’re wondering why you can’t find this in the repos, it’s because this is for Debian only. Don’t feel bad. You’ve got some fun stuff to play with too. …

kkm: For Debian fans with a wild streak

I felt a little bad that the earlier post about kbd didn’t really pull in the Debian crowd too, so I’ve got kkm here to keep you interested.

As I understand it, kkm is a wrapper to simplify apt-get and aptitude, and whether or not you like it will probably depend on your level of satisfaction with the traditional Debian commands.

And seeing as most of the Debian fans I know are fairly loyal to apt* and company, kkm might be a hard sell.

But if you’re both a Debian follower and a bit of a wild child, then this might work well for you.

Personally I see no fault in it, but I am a regular yaourt user … for much the same reasons that form the rationale for kkm. pacman is genius, I don’t deny that. But yaourt bridges the gap between pacman and AUR. 😈

If kkm can pull off the same stunt between apt-cache, apt-get and aptitude … well, you see where we’re going.

Anyway, no screenshot this time — my Debian machine is offline with hardware adjustments. You’ll have to install kkm and see what it looks like for yourself.

And then tell us what you think. Let’s see how many swirlies we can convert, shall we? And how many cling fiercely to aptitude‘s built-in minesweeper game. 😉

P.S.: Updated only days ago. … 🙂