Posts about sysadmin (old posts, page 1)

2006-05-14 09:39

Booting with runit / runit RPM - updated

I have updated my Booting with runit story for the commands in runit 1.5.1 and included a mention for my easy runit RPM (which is now also up to 1.5.1).

If you are looking for an alternative way to boot your linux machines, or for a reliable way to run and control your services, please take a look. Runit is cool.

2006-01-13 12:21

First piece of my "distro"

Here are runit RPM and SRPM for CentOS 4.2 (probably works on some other distros as well).

You install it, then clone your GRUB (or LILO) entry so you boot passing init=/sbin/runit-init to the kernel and when you boot it, it should start on a rather normal-looking runlevel 3.

To reboot or halt, use reboot-runit and halt-runit, please!

Keep in mind that this is just a beginning, since all your services (except your ttys :-) are still running without supervision!

Should not destroy anything, but use at your own risk.

You will have to work further if you want to do more.

Included is /etc/runit/services/test a trivial template service.

Sorry about the spammy hosting, but I will get a decent server space for these files somewhere eventually. These rpms are just a teaser, anyway :-)

2005-08-02 19:17

Deployments and stuff

Have been reading the planets lately (I mean and, not astrology) and run into posts by Aaron Seigo and Luis Villa which are, let's say, interesting.

Luis' post took me to this page which is interesting too, and I would like to see something like it for KDE (and I am sure it is somewhere, but I can't seem to find it)

And I don't mean the page is interesting only for having Australia listed as an asian country ;-)

Some of the items talk about hundreds of thousands (or hundreds of millions) of desktops, and others talk about 11 seats.

Is there nothing in the middle, or is it just not reported?

I decided to put out another datapoint.

Here in Argentina, the best-selling OS has KDE as the default desktop. It's a Linux from Pixart , and is more or less what on other countries is sold as Xandros.

It seems Pixart made some development work for Corel, and then for Xandros when they bought the linux distro business. Their boss is the former (?) boss of Corel argentina, too.

Almost every whitebox clone is sold with one of their distros installed and preconfigured.

Oh, sure, most of them get wiped out and replaced with a stolen windows xp in 24 hours, but it's quite a number. Think 100K or 200K sold each year, at least.

Of some concern is that some of the GNOME deployments used to be KDE deployments. For example, the Sao Paulo telecentros used to be Conectiva boxes with KDE (and windows, in dualboot).

The City of Largo used KDE for quite a while.

But what the heck, we are both desktops squeezed into a ketchup bottle, there's a whole world outside to spread into ;-)

2005-03-20 23:59

UNIX stuff that makes no sense ( the rant)

First of all, I love Linux. I have used it exclusively since about 1994 (yeah, the last Windows I actually used for real was WfW 3.11).

Let's see how it makes no sense.

The Bin

Your system has /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin 6 different binary locations.

What sense does it make to split bin and sbin? It only makes it harder for regular users to use tools the can need, like netstat and ifconfig.

As for /bin and /usr/bin, it makes little more sense, if at all. Sure, put a basic, functional system outside /usr, because /usr can be a network FS. Well, who does that?

I mean, I have seen all-local and all-network systems, but I have never seen a /-local, /usr-remote system in ten years.

And I suppose someone does it, but that doesn't mean it makes sense. If you want a real, functional, unbreakable system you can use in case of network failure: use a separate partition. Or use a Live CD. Or use a floppy. All of those are more resilient than your /.

As for /usr and /usr/local... that's just a throwback to when people were scared of installing software. People should install packaged software anyway.

The Libs

/lib /usr/lib and /usr/local/lib. Just as much sense as the above.

The variable

/usr and /var. Here's what I think I heard: /usr is for unchanging application data (bins, libs, docs, etc.) /var is for mutable data (logs, spools, caches).

That way, you put /var in a separate partition and if apps run amok, your / doesn't fill.

Well... ok, I suppose. Except that the right way to handle that is to make sure your apps don't freaking run amok!

Say, logs? Rotate them by size, not by date!

Spools? Use disk quotas, and maximum sizes!

Caches? They should be space-limited.

And all services should be kind enough to figure out when your disk is about to burst and do something graceful with it.

Finally: if your /var fills, all your services will crash just as hard as if / filled. So what's the point? That you can log into the crashed box and fix it? You can do that with a full /, too.

The root of all evil

We live with the concept of a single almighty admin. Why?

If every service application had a single point of configuration and monitoring (ie: /etc/app and /var/service/app (in runit ;-) and /var/log/app, it would be trivial, using ACLs, to allow partial management of the system.

Sure, there would be a real root for stuff like password management and such, but that's not so bad.

Why has no one bothered doing this?

Permission to barf

The Unix permission system is at the same time harder and less powerful than ACLs. That only on the last two years it has become practical to use ACLs on Linux, and that still you can't count on them in every distro is... ugly.

I could go on, but... I think you get the idea. Coming some day: a proposal to fix the mess.

2005-03-19 23:59

Booting with runit

The first tutorial coming from my custom-distro experiments. Since it's a good idea to start at the beginning, here is... Booting with runit.

2005-03-17 23:59

Linux: a not-unix-like OS.

Well, I am still experimenting with my concept-distro.

I am now up to a running PyQt using uClibc, which I thought unlikely ;-)

I completely removed all the sysv init stuff, and replaced it with runit, which has an interesting effect:

It boots to a graphical login in about 15 seconds. Inside qemu. In a 900Mhz duron. Including kernel loading.

Of course the trick is that you have the login while stuff is still loading, but I am working on that, too.

Since using runit it's pretty simple to get a overview of where the booting process is (services have dependencies, they simply get started in order, and in parallel), I will hack a system-wide ksplash-like thing on a side of the xdm (probably will end up writing my own whateverdm).

Think of it as Fedora's rhgb, only you can login instead of getting bored.

I also switched to a root-free system Ubuntu style. Not decided yet on it, but it's not hard to do (or use).

Next step: hack Knoppix HW-detection script (or rather rewrite them in a real language).

I understand why there are 743 Linux distros. It's quite a lot of fun to hack one together.

Oh, and it needs a name. It's not going to be useful for anyone, it's just a personal toy, but it needs one.

Come on, Planetkde guys, throw me names for a non-unix like linux, if you dare ;-)

2005-03-15 23:59

Source-based distributions, the good side.

I am no fan of source-based distributions. I think that for most practical purposes, a distribution where installing KDE takes over a day (I own a lowly Duron as my fast computer) is useless.

However, they are good for one particular niche.

Custom distributions. Weird distributions. Personal distributions.

I have several computers. Most of them too slow and small.

As I was considering reinstalling Linux on my Libretto for fun, I looked at what was installed in it, and decided that really, 90% of it was of no use whatsoever.

The problem was, since it had Debian installed, it has a rather wide network of dependencies that simply could not be done without.

On a regular computer, that's not an issue, but in this tiny workhorse, with 16MB of RAM and a 800MB HD, it makes a lot of difference. The smallest I could get Debian to be, and still have network, PCMCIA and X11, was about 250MB.

And the performance was not awesome, either (but not terrible).

So, what would happen if instead of a regular distribution it had something like this:

  • uClibc instead of glibc
  • runit instead of SYSVinit
  • dropbear instead of OpenSSH
  • X built as kdrive (formerly tinyX)
  • python/qt (or maybe python/fltk) for basic admin tools

And so on. Basically rejigger the whole software selection slanting it towards the small side, and dropping a bazillion non-fundamental dependencies along the way.

Well, it can be done. It's just that it's a heck of a lot of work. But here, a source-based distribution gives you a headstart.

For example, I decided to start from ucrux, a uClibc-based port of Crux. Since the native toolchain in ucrux is uClibc, I don't have to worry much about a whole class of mess that happens when you build uClibc-based binaries on a glibc-based system (it's practically cross-compiling).

Qemu lets me install ucrux and work on it somewhat faster than on the target P75 (if I could make KQEmu work I'd be happiest).

Since crux's software packaging mechanism is simplicity itself (a shell script that installs to a fake root), although it's severely underpowered (no dependencies), I can start from ucrux, hack the build of one package at a time, then put everything on a CD very quickly.

So, if you want to hack your own distribution, Crux (or some other similar kit) is quite a nice thing.

For general use... well, my requirements start at apt-get or equivalent ;-)

Now, if only TinyCC worked for more programs, that P75 would be a pocket development powerhouse!

2004-10-13 16:03

Adventures in Hi-Fi

As I blogged earlier I am writing a game (and yes, it's pretty much playable already).

One thing I didn't mention is that I never wrote a game before. Yeah, I know everyone does it as one of his first projects, but I never did.

So, there are some things I really have no clue about [1], like sound and moving graphics around.

For the graphics stuff, QCanvas is just fine and dandy, but to make things bloop and warble and squeak when the time is right, I found Qt's sound support somewhat depressing.

Come on, NAS? Who uses that? And what about music? I had no idea.

So, I started trying to follow one of my leading principles of development: find a way to make it Someone Else's Problem (TM).

The usual way to do that is finding a library that handles the problem, write minimal glue, stick it to the side of the program, tell the program that's his new arm, and forget about it quickly.

Here's what I found.

Mi Dios!

I thought I should start by adding one of those annoying little tunes every game has. It's just a game tune, I don't want to have to include a 3MB OGG file for it, so I wanted an instrument-based format.

I remembered MIDI tunes. You may know them as ringtones nowadays, but they used to be just cheesy tunes generated by your SBPro's FM generator, not your phone.

In fact, I remember having a little proggie called playmidi, that would do that in Linux.

Well, it seems that in the past few years, either sound cards have forgotten how to play them, they fell out of fashion, or something, because the only things I found that could play MIDI are monstrosities that require a 9MB digital instrument set. And how was I to include that along with my 25KB game???

So, what's next? I had a C64, so...

MOD me up!

MOD files are like MIDI files, only the MOD includes it's own instrument set, called samples, and instructions on how to repeat and alter those samples to make a tune.

Good news: there are nice-sounding, funny MOD files that are about 30KB in size.

Better news: There is a popular library to play them! It's called Mikmod, and your distro has it (and it's a dependency for KDE's multimedia packages too).

Even better news: It has support for playing simple sounds (samples in mod lingo) by calling a couple of functions.

Awesome news: It includes a software mixer so you can just tell it to play this, then play that, then that, and a tune in the background, and everything sounds at the same time.

So, we have a winner. This baby can handle everything I need for the game!

But... is that a snake in your pocket?

I can't find a Python binding for it. I am sure as soon as I post this article someone is going to come up and tell me, here they are, moron! But I just can't find any.

So, I decided to do something I wanted to do already and learn to use Pyrex. Pyrex is a tool to write python extensions, with almost-free access to C libraries, in an almost-python language (only minor syntax differences).

That way, I could write a Python module to use Mikmod.

You know what? It was almost scarily simple [2]. I didn't wrap all of Mikmod [3] because I don't need it, but now I can do stuff for games and apps almost trivially.

Even more: Pyrex has awesome distutils support, so building the extensions, usually a pain in the rear, is trivial (mostly you just copy and delete stuff, with some search and replace).

One thing I found I did nicely is this: Mikmod requires you to call Mikmod_Update every once in a while so it fills the soundcard's buffer with stuff to play. If you don't, it skips.

So, I just started a thread that loops and takes care of it. You don't even have to know about it to use the extension. Oh, sure, if your Mikmod is not threadsafe, it breaks. Well, get a decent Mikmod package, then.

How does it look?

Here's a whole noisy proggie

#Load the modules
import mikmod, time
#Init the library
#40 voices, 20 for music, 20 for random sounds (overkill)
#Enable sound, starts the thread that pushes sound, too

#Create a module, that is, a music track

#Load two samples, just a couple of noises

#Start playing the song

#For the duration of the song, each second, make some noise


#Close the mikmod library, stop the thread, etc.

[1] As if that would surprise anyone!
[2] On the other hand... waiting for stuff to compile... how quaint.
[3] Actually, I am wrapping almost all of Mikmod, I am just not exposing it to Python because I don't need it.

2003-12-20 13:07

Well ordered toolkits

I think some months of formal math training would do wonders for the average guy.

And I don't mean algebra, I mean logic, set theory, that kind of thing.

The obvious example is, of course, comparing two things. There is the concept of the well ordered set. In a well ordered set, for any subset, there is a larger and a smaller member.

In other words, if you compare any group of things, one is the largest, one is the smallest.

That may seem obvious, because people only think in terms of integer or real numbers when they see > , but real life is different. Real life objects are usually not well ordered, and that means you can't sort the whole set, nothing ever comes out on top.

Because the crappy math people learn makes them think in linear terms [1], reality is approached in linear, limited terms.

what I am thinking about:

People say Qt is better than GTK+ or viceversa.

Well, those are multidimensional objects you are comparing, and in order to make it meaningful, you need to establish a metric that will make the toolkit-space a well ordered set.

That metric, sadly, is subjective and personal. While Bruce Perens[1] may see the acquisition cost for proprietary developers as the most significant part of it[2], others may see techical features as more important.

But the telling point is this:

If you are a free software developer, why would you choose GTK+? What is your metric, where GTK+ is larger?

I really have no clue on that, since I haven't touched GTK+ since I recoiled in horror from it in early 1996, but I will try my best.

  • You prefer coding in C
  • You want your app to work well with GNOME
  • You find the GTK+ API appealing
  • You like some GTK+ development tool, like glade
  • You see better performance in GTK+ than in other toolkits

I can't find any other reasons, and even one or two of those seem iffy to me ;-)

You prefer coding in C: Ok, that's reasonable. If you want to code in C, GTK+ is probably the way to go.

But why, oh, why do you want to do that? Really, come on, C is a poor language for almost every use. Your language metric is probably the guilty part of your choice of GTK+. But that's another set.

You want your app to work well with GNOME: Ok, that is reasonable. I could say Qt apps work well with GNOME, too, but that's my own subjective bias, and really not defensible, since GTK+ apps do work better with GNOME.

The GTK+ API is appealing to you: you are a sick person? ;-) Ok, that was harsh: you have bad taste in APIs? Ok, that was still harsh: I don't understand you. Yeah, that's better.

Luckily, you don't have to use it, you can use decent wrappers, nowadays.

You like a development tool, like glade: I don't see glade as a big thing compared to others, but hey, that's just my taste. Reasonable point.

Performance: You want performance? Use fltk. Even pure Qt seems to be about on par with GTK+. Of course if you pair this with the C argument, they sinergize. After all, GTK+ does have better performance than Xaw3D or somesuch. Maybe XForms?

Please, if anyone reads this, I am not trying to flame GTK+ or its developers. I am sure GTK+ is the greatest C toolkit around, and developed by smart people.

I just also don't see any compeling reason to use the thing for free software development. For proprietary coding? Maybe, if you are low in cash. My own metric (for whatever little it's worth) doesn't make me see GTK+ as an interesting tool. If yours does, please help me improve it.

Yes, I know stuff like saying the API is ugly can't be improved, because you can't convince me that it isn't[4], but you can help provide new reasons, or strengthen others, or maybe tell me bad points about the toolkit I see as better.

[1] Ok, people think that way even if they don't learn math, the thing is, math teaches you to think non-linear, or multidimensional.

[2] An interesting fellow. Remember when he quit Debian in a huff?, and that he was going to develop a Red Hat-based distro that was more desktop-oriented? That was probably around 1998 or 1999, IIRC. BTW: you won't find all of it in the Debian archives, "someone" removed it.

[3] Which is really a bizarre argument, isn't it?

[4] I also think most of Dalí's and Picasso's paintings are ugly. How can anyone convince me they aren't? They can't.

2003-12-01 13:01

Playing with Flonix

A Linux distro in my USB keychain. I will do a writeup on it in a day or two, probably, since the plan to work less is working (tuesdays and thursdays off already :-)

Contents © 2000-2019 Roberto Alsina