Ir al contenido principal

Ralsina.Me — El sitio web de Roberto Alsina

Publicaciones sobre linux (publicaciones antiguas, página 11)

To the other three guys (or gals)....

... who own a HP Jor­na­da 720 and are us­ing Opie on it and they have the span­ish/lat­in-amer­i­can key­board­... here is your keymap.

I will write some­thing about how to get Lin­ux go­ing right on it soon, but here's the sta­tus re­port, 48 hours in.

This ba­by (un­named yet) has:

  • 32MB of RAM

  • 1 GB of Flash

  • Wifi (802.11b pcm­­ci­a) + IR­­DA + Eth­er­net (pcm­­ci­a) + Any­thing once I find a 16-bit pcm­­ci­a-USB card (any­one has a spare and wants to re­­cy­­cle it? ;-)

  • De­­cent bat­tery life (6 hours use with wifi, 9 with­­out)

  • A key­board

  • A de­­cent screen (640x240)

  • A de­­cent Lin­ux-based GUI (Opie)

  • A some­what er­rat­ic touch­screen

So, what can I do with it:

  • Email

  • Web brows­ing ( With Kon­­queror good­­ness )

  • Pro­­gram­ming (Python, even PyQt2!). They key­board and screen are sur­pris­ing­­ly de­­cen­t.

  • eBook read­­ing. This is the most im­­por­­tant one. In my work, I spend a lot of time wait­­ing. Wait­­ing for the train to ar­rive, for the trip to end, for some­one to come to a meet­ing, for the wait­­er to bring my meal, for stuff to com­pile, for stuff to down­load­­... maybe I wait 3 hours a day. So I read. And this screen (long and some­what thin) is quite spec­­tac­u­lar for read­­ing. Opie-read­­er is pret­­ty good.

  • MP3 and Video play­er (haven't used it yet). I have stream­ing TV at home, cour­tesy of Cher­ryTV (check the links at the left­­). This should work great when Rosario wants to see Mon­te­cristo and I'd rather see Penn & Teller's show.

  • Gen­er­al PIM stuff. Al­though I tend to keep that stuff in my head and my phone.

The bad side:

  • The bizarre screen as­pect ra­­tio con­­fus­es many con­­fig­u­ra­­tion di­alogs.

  • Al­­most no game works un­­less you ro­­tate the screen.

  • The key­board con­­fig­u­ra­­tion took a while, and is not per­­fect yet ( I can't make dead­­_a­­cute work for some rea­­son)

  • The ex­­tra but­­tons don't work (ex­ter­­nal au­­dio recorder, and alarm light-but­­ton)

  • I can't find a way to bind the func­­tion keys to apps in Opie

  • The re­set but­­ton does­n't work (it's now a hang but­­ton)

  • Sus­pend is not re­al­­ly sus­pend on Lin­ux (for un­avoid­able hard­ware rea­­son­s), so it spends bat­tery when sus­pend­ed (may last 12 hours or so, I think).

  • The on­­ly way to re­al­­ly turn it off is to take out the bat­tery (not as bad as it sound­s).

  • If you do that, it takes about one minute to boot.

So, I am us­ing it more as a lap­top (although a re­al­ly, re­al­ly small one, with very, very good bat­tery life :-) than as a PDA.

The small mem­o­ry and CPU means I can't run very de­mand­ing stuff, but I nev­er seem to do that, any­way.

And of course, the re­al­ly bad thing: it's so much fun to hack with, I have trou­ble work­ing!

All in al­l, a great toy, lots of fun, and rather use­ful.

No, I don't get a dime from them

For a few months I have been us­ing an un­man­aged vir­tu­al pri­vate serv­er from Tek­ton­ic, and I love it.

What's that? Let's take it one word at a time, and then some more.

  1. It's a serv­er: which means it's a ful­l-ish lin­ux in­­stal­la­­tion. So it is ca­­pa­ble of do­ing lots of things. I can run all sorts of weird python thin­­gies in it if I wan­t. IMAPS and SSMT­P? No prob­le­­mo.

  2. It's pri­­vate: which means I am root on it. I have the shel­l. I choose what to in­­stal­l.

  3. It's vir­­tu­al: it's a Vir­­tuoz­­zo par­ti­­tion in a re­al serv­er. That means no cus­­tom ker­nel mod­­ules, and that since al­­most ev­ery­thing is shared with oth­­er in­­s­tances, 5GB of disk and 128MB of RAM go a long way.

  4. It's un­­man­aged: which means I man­age it. Which is just the way I pre­fer it, since that's my job.

  5. It's cheap. I start­ed on a 8 dol­lars a month plan (which does­n't seem to be there any­­more, the cur­rent cheap­­est is a 15 dol­lars plan).

  6. It's a throw­­away. I want to host some client as a favour? I just put it there. I could even rent an­oth­er of these servers for a while, use it, then close it. Back­­up­s? Click­­ing on a we­b­­page saves the im­age! Oth­­er than that... I back it.

  7. Fixed IP­s. All you want (for ex­­tra coin­s).

  8. A home away from home. All my stuff is there. I need it, I get it. With­­out both­­er­ing about hav­ing my own serv­er at home via no-ip or some­­such (which of course I still have too ;-)

  9. It works. It hard­­ly ev­er break­s. And hav­ing sur­­vived ex­pen­­sive, man­aged server­s, this ba­­by is work­ing just as well.

  10. It's a nice gift. Sup­­pose you have a con­nec­­tion to a free soft­­ware pro­­jec­t/LUG/­­fam­i­­ly/what­ev­er, and they need a place on the in­­ter­net. Why not spon­­sor them with some­thing like this? I of­fered one to PyAr (which did­n't take it, but it's the thought that counts ;-)

  11. The ul­ti­­mate learn­ing ex­pe­ri­ence: you can re­­s­tore the sys­tem in 2 min­utes. Want to play/learn sysad­min­ing? Do it on the re­al vir­­tu­al thing! Much cheap­­er than hos­ing your own box ;-)

  12. They of­fer a good ser­vice. So, peo­­ple should know about it. And of course... if you know a sim­i­lar, but even bet­ter deal... I'm all ears!

A different UNIX Part II: A better shell language

One of the things peo­ple study when they "learn unix" is shell script­ing and us­age. Be­cause ev­ery sys­tem has a shel­l, and if you learn to use it in­ter­ac­tive­ly, you are half way there to au­tomat­ing sys­tem tasks!

Let's con­sid­er that for a mo­men­t... what are the odds that the same lan­guage can be good for in­ter­ac­tive use and for pro­gram­ming? I say slim.

Not to men­tion that learn­ing shell as a way to learn unix is like go­ing to a school that teach­es TV pro­duc­tion, and study­ing the re­mote. While use­ful, not re­al­ly the im­por­tant tool (ok, that anal­o­gy does­n't work at al­l. But it sounds neat, does­n't it?).

The first thing is that to­day's Lin­ux dom­i­na­tion of the unix­sphere has caused a se­ri­ous mono­cul­ture in shell script­ing: ev­ery­one us­es bash. The more en­light­ened ones may check that their scripts work on some oth­er Bourne-style shel­l.

There are no im­por­tant dis­tri­bu­tions (or pro­pri­etary unix­es) that use a csh or any­thing like it. De­bian has a pol­i­cy that things should work with­out bashism­s. That's about as good as it get­s.

Writ­ing a dozen pages on how shell sucks would be triv­ial. But un­in­ter­est­ing.

So, let's think it over, and start from the top.

What should a shell script­ing lan­guage be like?

What does­n't mat­ter?

Let's tack­le these things. I in­vite any­one to add ex­tra ideas in the com­ments sec­tion.

What should a shell scripting language be like?

  • In­­ter­pret­ed (ob­vi­ous)

  • Dy­­nam­ic typ­ing (y­ou will be switch­ing ints to strs and vicev­er­sa all the time).

  • Easy in­­­cor­po­ra­­tion of oth­­er pro­­grams as func­­tion­s/meth­od­s/what­ev­er.

    That pret­­ty much is what makes it a shel­l. ls should be in­­dis­­t­in­guish­able from some­thing writ­ten us­ing the shell it­­self.

  • Pipes. This is a must. Unix has a bazil­lion tools meant to be used in com­­mand pipe­­lines. You can im­­ple­­ment a RDBMS us­ing that kind of thing (check out nosql). Lev­er­age that.

    But even here, on its strength, the shell is not per­fec­t. Why can't I eas­i­­ly pipe stderr and std­out to dif­fer­­ent pro­cess­es? Why can't I pipe the same thing to two pro­cess­es at the same time (yes, I know how to do it with a neat trick ;-)

  • Glob­bing. *.txt should give you a list of files. This is one of the ob­vi­ous things where sh is bro­ken. *.txt may be a string or a list, de­pend­ing on con­tex­t... and a list is just a se­ries of strings with blanks. That is one of the bazil­lion things that makes writ­ing shell scripts (at least good ones) hard:

    [ralsina@monty ralsina]\$ echo *out
    a.out
    [ralsina@monty ralsina]\$ echo *outa
    *outa
  • A list da­­ta type. No, writ­ing strings sep­a­rat­ed with spa­ces is not ok. Maybe a python-style dic­­tio­­nary as well?

  • Func­­tions (ob­vi­ous)

  • Li­braries (and ok, the shell source mech­a­nism seems good enough)

  • Stand­alone. It should­n't spawn sh for any rea­­son ;-)

What doesn't matter?

  • Per­­for­­mance. Ok, it mat­ters that a five-­lin­er does­n't take 50 min­utes un­­less it has to. But 1 sec­onds or two sec­ond­s? not that im­­por­­tan­t.

  • Ob­­ject ori­en­­ta­­tion. I don't see it be­ing too use­­ful. Shell scripts are old-­­fash­ioned :-)

  • Com­­pat­i­­bil­i­­ty to cur­rent shel­l­s. Come on. Why be like some­thing that suck­­s? ;-)

Now, the example

Let's con­sid­er a typ­i­cal piece of shell script and a re­write in a more rea­son­able syn­tax.

This is bash (no it does­n't work on any oth­er shel­l, I think):

DAEMONS=( syslog network cron )

# Start daemons
for daemon in "\${DAEMONS[@]}"; do
      if [ "\$daemon" = "\${daemon#!}" ]; then
              if [ "\$daemon" = "\${daemon#@}" ]; then
                      /etc/rc.d/\$daemon start
              else
                      stat_bkgd "Starting \${daemon:1}"
                      (/etc/rc.d/\${daemon:1} start) &>/dev/null &
              fi
      fi
done

And since DAE­MONS is some­thing the ad­min writes, this script lets you shoot in the foot in half a dozen ways, too.

How about this:

DAEMONS=["syslog","network","cron"]

# Start daemons
for daemon in DAEMONS {
      if ( daemon[0] != "!" ) {
              if ( daemon[0] == "@" ) {
                      stat_bkgd ("Starting "+daemon[1:])
                      /etc/rc.d/+daemon[1:] ("start") &> /dev/null &
              } else {
                      /etc/rc.d/+daemon ("start")
              }
      }
}

Of couse the syn­tax is some­thing I just made up as I was writ­ing, but is­n't it nicer al­ready?

A different UNIX Part I: Mail in not-mail-servers

I have been pro­cras­ti­nat­ing about cre­at­ing my own Lin­ux dis­tro for at least three years. Guess what? I will still pro­cras­ti­nate about it for a few more, but that doesn mean I can't write about how it's sup­posed to work ;-)

So, here is a first piece of the puz­zle...

What do I mean by "Main in not-­mail-server­s"?

If by mail serv­er we mean a box that has the re­spon­s­abil­i­ty to han­dle send­ing mail for user­s, non-­mail-servers are all the rest.

And what is it they do with mail? They gen­er­ate it. Both the users and the pro­cess­es of those box­es gen­er­ate mail. They do it for cron job­s, they do it for main­te­nance pro­cess­es, they do it for alert­s, what­ev­er.

And what is it they do with that email? They send it some­where.

Usu­al­ly, they send it to them­selves. Which is a pret­ty use­less thing.

Go now and check the root mail­box in your com­put­er­s. I bet most of you have a bunch of mails in them you nev­er checked. Ei­ther it's im­por­tan­t, in which case you should have placed it in a mail­box you ac­tu­al­ly read, or it's not, in which case it's use­less to store.

In any case, it should­n't be there.

How does your box send those mail­s? Us­ing ei­ther the send­mail bi­na­ry, or the mail pro­gram (prob­a­bly mailx), which us­es the send­mail bi­na­ry.

Just be­cause it's called send­mail it does­n't mean it is send­mail, of course. Post­fix and qmail pro­vide a send­mail wrap­per to in­ject mail in­to their queues.

But the main prob­lem is that us­ing those means you need to have a well con­fig­ured mail serv­er in ev­ery box, even if they are not mail servers! Yes, your dis­tro gives you a de­cent con­fig­u­ra­tion by de­fault which makes things usu­al­ly work... for lo­cal mail de­liv­ery at least. Which is prob­a­bly not re­al­ly what you wan­t.

En­ter null­mail­er. A sort of heav­i­ly se­dat­ed, neutered qmail.

Con­fig­u­ra­tion:

  • De­­fault do­­main name of out­­­go­ing mail in /etc/nul­l­­mail­er/me

  • List of SMTP servers in /etc/null­mail­er/re­motes:

    mx1.mydomain.com smtp --user=ralsina --pass=notmyrealpass

You can put sev­er­al, it will try them in or­der.

And that's that. A tiny ser­vice, which us­es no TCP port­s. The whole thing is 59KB (or less if you use di­et libc), has one SUID bi­na­ry (but it is not SUID root), two con­fig files (both one-­lin­er­s), no need for alias­ing the sys­tem user­s.... and you can re­move post­fix/send­mail/q­mail from most of your server­s.

Sounds like a good idea to me.

Long update

I have not post­ed in a long time, not be­cause noth­ing hap­pened, but be­cause too much hap­pened.

So, here is an up­date...

Ba­by

The ba­by is do­ing great. The first ul­tra­sound was on Sep­t. 15th, and hree he is:

ecografiaPoroto

Birth­day

That was on Sep­t. 15th be­cause Rosario want­ed it to be my 35th birth­day presen­t. So hap­py birth­day to me.

Work

The lit­tle com­pa­ny I am start­ing up is do­ing great

Hob­by

I have de­cid­ed that I have al­most enough pack­aged for Arch that it's start­ing to make sense to mas­ter some ISOs. Ba­si­cal­ly: a some­what-D­JB-way-ori­ent­ed lin­ux dis­tro.

  • Boots us­ing runit

  • Maybe some­­day will use LUA in­­stead of sh for start­up scripts

  • All ser­vices should be man­aged

  • Will in­­tro­­duce ge­net­ic di­ver­si­­ty to the ecosys­tem

That mean­s: no send­mail, no post­fix, no BIND, no Apache (at least for ba­sic stuff), no many oth­er "lead­ing" pro­gram­s. That is in­ten­tion­al. If ev­ery­one us­es BIND, a BIND fail­ure is cat­a­stroph­ic.

If I have learned any­thing from Out­look/IE it's that hav­ing ev­ery­one use the same thing is com­fort­able, but trou­ble­some.


Contents © 2000-2024 Roberto Alsina