How to install Debian in qemu via console only...

Running Debian in a qemu VM on a remote machine is useful in quite a few cases, such as setting up KVM instances or preparing CompactFlash cards to bring up old laptops. This qemu command will bring up a serial console based installation session that even works in screen:

qemu -hda /dev/sdc -cdrom firmware-testing-i386-netinst.iso -boot d -kernel /mnt2/install.386/vmlinuz -initrd /mnt2/install.386/initrd.gz -nographic -append "fb=false console=ttyS0"

or, when doing a CF-destined install:

qemu -hda /dev/sdc -cdrom ~/emu/firmware-testing-i386-netinst.iso -boot d -kernel /mnt2/install.386/vmlinuz -initrd /mnt2/install.386/initrd.gz -curses -append "fb=false"

In my example I directly booted the kernel using qemu, with the debian image on /mnt2. hda is an 8GB Sandisk Ultra CF card (available for $35 at Costco)

From here it's pretty much the regular debian installer...

preliminary spec: using old headless laptop as a network kbd+mouse

I'm pretty tired (at 1PM on a saturday. how lame!) but I'm scoping out an idea to use old headless laptops to work as mouse+kbd. I have a headless thinkpad t20 with pxe support (I think) that would work nicely for this.

These are notes mostly for myself on how this thing oughta work. I'll probably use OpenWRT with a uicat/client package (which I need to write) with uiclient autostarting.

Eventually this could be expanded into a full "drone" distribution capable of being a remote video player. Probably still OpenWRT based with a LUCI interface to set up wireless networking(?) although that needs non-volatile storage. But that doesn't have to be on the actual drone...

Now to get my brain together enough to write this silly thing... ;)

Pieces:

- Old laptop, booting via IDE-CF, USB, memory-loading CD, or network. Network must be present and support DHCP.

- (new) uicat (uinput cat, ala netcat) - can work with netcat to stream mouse/kbd in either direction.

- (new) uiclient (uinput client) - like uicat, but with extra commands on the client side.

Using a suitably loaded Linux, the uinput-drone system will automatically start. "blind" operation is fully supported (think headless laptop) and a special key sequence can be used to link up to a uicat "server" listening for a connection on a given port.

Once the Linux is loaded, the num lock LED will blink every second. Then press the caps lock key and the capslock LED will blink instead. Then type in the IP address of the target computer, and hit return (or escape to abort on a typo). It will then try to connect to the target, and if it works all two/three LED's will blink for one second. If an error occurs it will probably just go back to blinkiing num-lock.

After that, all input events will be 'tunneled' over the network and they will look like native events to the other computer.

To end a session, use control-capslock-enter? Something that isn't commonly used at least.

---

V2 of the uidrone system will support xorg (newest) with mplayer? so that it can be used as a remote video player as well. This mode would be quite useful for TV out, since many older laptops have S-Video output we can probably use.

copypasta from an ars thread-post i just made...

I figured out that WP7 was DOA a few days ago... why?

Because Microsoft is throwing *everything* out, and blindly copying the *worst* things Apple did that completely remove what strengths Windows Mobile *did* have. No multitasking (because iPhone doesn't have it) and a locked App store (because Apple has it)

Combine that with breaking back-compat (so *not* Microsoft) and relying on their development flavor-of-the-month, and it's a 'me too' product - all the downsides of Apple but little to none of the magic.

If Microsoft had a clue, they would've put in Enterprise features and they would have much of RIM's marketshare, and would be able to maintain their current positioning. (RIM should be ok, at least once they get the Webkit browser... the 9700/OS5 is quite similar to Android in *some* ways... enough to keep the customer base from jumping off IMO.)

The other huge problem? The web browser is going to be garbage compared to Webkit - which because Apple based it on KDE's browser, has to share... leading to everyone else using it. WM6.5's IE only gets 5/100 on Acid3, and I doubt WP7's will be anywhere near 100.

(IMO Webkit might be the one of the most significant software packages of the 10's...)

As for Symbian - a friend of mine got a Nokia from AT&T free w/contract - disguised as a non-smartphone. If Nokia can keep lower end Symbians enough like series 40, they'll quietly keep selling 'em. And in the Webkit/HTML5 era, Symbian^3 should do just fine.

Eventually simpler apps will all be HTML5+Javascript (hence me actually *rooting* for Steve Jobs in his Flash war. *nobody* else could win it...) and everyone with a decent browser will have a usable smartphone. It'll just be easier to pick up Android or perhaps Symbian now that it's opened.

Microsoft, having too much pride to adopt Webkit, might miss out on the party for years.

on the iPad and computing in the 10's...

I'll start with this: if you're at all interested in picking up programming, start with Javascript and write basic web pages and apps with it. It's the BASIC of the 10's... no, it's actually far more pervasive. ;)

---

I haven't actually played with an iPad yet (I was sick this weekend, and I don't really have $499-599 right this second... *glances at 32" LCD*) but I think it's a turning point.

Basically, it's one step closer to the computer that isn't there - something that fades away into the background. Getting rid of the keyboard might be risky, but...

... the iPad is a consumer device. It's not about writing, drawing, or creating content.

That's where the "PC" of the 10's comes in against the iPod's "Mac."

---

Android is nice, but one little piece fell out of their pre-planning that hurts it:

It's Javascript that matters, not Java.

---

Javascript is a very interesting language, wrapped in C semantics, various web browser crap, and labeled Java* to throw off any PHB's that would kill it off for actually being innovative.

But it managed to bring quite a few academic ideas into the real world - first class functions, lambdas, closures, dynamic code execution, etc.

Go to http://www.crockford.com to find out more.

---

Javascript could have gotten away with being as bad as it's rep, though. Think of a modern computer, sold to consumers, that doesn't have Javascript in it, in some form or another.

*chirp*

But partially because it *is* a very mallible language, and because webstuff is just *that* popular, it'll be tinkered around with until you can do anything that a low-complexity program needs to do.

For instance, you can make a basic iPhone app in html+javascript, provide it a manifest file, and it'll store it on the iPhone locally and even hide the location bar for you. (This is how the second pass at Google Voice works...)

---

Once you realize that HTML5+javascript can make decent apps for iProducts, it makes the store lock-down a *little* more tolerable. But to get to everything you still need native code, which means dealing with Apple and their censors. Blah.

---

Microsoft is now out of their element. Windows Mobile 7 will likely still be a 'me too' product, although it's their last chance to make something that *isn't*, especially since they're throwing backwards compatibility out the window, which is *very* non-Microsofty...

---

I really do think Apple's anti-Flash stance is the best thing for the entire computer industry, although part of that might be by accident. It's encouraging people to figure out just how far HTML5 can go and from there how unnecessary Adobe's bloated buggy plugin is.

(Yes, I know it's really because Steve's a control freak...)

---

It's time for the next generation of Linux GUI's to start coming about - one that can perform as well as the iPad's. Android will probably have to do for a year or two, but the real competition will come from a more web-centric engine.

---

At the very least, tech from Linux projects tend to resurface in odd ways. Like my Panasonic 32" TV (among others!) having the GPL and LGPL texts in the menu system!

And while Firefox had the biggest mindshare - at least for a while - Apple's move to commercialize KHTML and KJS into Webkit took some KDE code and made it what I think'll be the preeminent web browser engine this decade.

Being lighter-weight than Mozilla's engine, it has been picked up by almost everyone making mobile browsers - except Microsoft, and from what I can tell mobile IE is crap anyway. (The browser in Winmo 7 had *better not* suck, or it's DOA)

And Webkit runs well on full-size computers, too.

---

I have a nice used X41 Tablet I got for <$300 recently. It'd be nice if it had a finger touchscreen, but maybe that's where I should start experimenting with iPaddy stuff...

---

Current geeky plans...

- mini-Javascript interpreter (measured in xxK, or hopefully even xK, if possible)

- Getting Linux on my msntv 2 (RM4100 - Celeron 733, 128MB ram, i830, etc...)

- blipvert - flexible audio time compression (need to make it a sox plugin)

It's time for another (attempt at a) month of posts about stuff I'm doing...

It's very easy to make complex systems using pipes and other simple UNIX shell techniques, if you know how to fully exploit the properties of what you're using.

This is a great example - a two-line streaming system suitable for both recording DV and streaming it to an overflow room @ a conference:

record side:
dvgrab - | ffmpeg -f dv -i - -vcodec mpeg1video -deinterlace -bframes 0 -b 2048k -ab 128k -f mpeg - >> test.mpg

This runs fine on a P4/2.53B (Northwood) system with 512MB ram - easily obtainable for <$100 if you have a good local source.

MPEG-1 video and mp2 (not mp3) audio with no B frames are no longer patent-encumbered and are much faster than Ogg Theora, and with far wider software support. Almost all MPEG-2 decoding systems can deal with MPEG-1 files, and all properly coded mp3 players can play mp2, which can sound really good at 224Kb/sec (VCD bitrate)

mplayer is able to jump into MPEG-1 PS files mid-stream and handle new encoding sessions. So using >> for ffmpeg's output is quite reasonable and provides robustness if the DV capture fails, since dvgrab|ffmpeg can be put into a loop.

You can use other capture systems as well - anything ffmpeg supports, which is quite a lot. You just need to adjust the input-side -f parameter to tell it what to expect.

viewer side:
ssh 192.168.1.40 "tail -f -c 1024 test.mpg" | mplayer -cache 512 -

This is also very simple. It makes an ssh connection to the recording host. tail (at least with -c) is 8-bit clean so you can stream MPEG-1 data through it to mplayer, which can jump in at any point.

There are many different ways to handle the viewer. netcat would work, and anything that can deal with MPEG-1 from standard output, starting mid-stream can be used as a player. mplayer is just the most common one on Linux.

Here's some code I've been playing with as part of that odd language concept. It converts binary, decimal or hex #'s and is 180-300 bytes -Os depending on CPU.

thumb2 really is small - it comes out about 70 bytes shorter than x86. Good for when this code's running on -m3.

It has error but not overflow checking and is written to work at native word size.

Hoping I can get my language running on the AVR as well eventually - ideally I'd have the core running in 2-4K as a bootloader. For some things there's nothing cooler than an 8 or 20-pin DIP chip. . o O (for everything else, there's master^WARM)

/* This flexible parser handles sign, dec, and hex bases while maintaining error checking */

/* Slightly less than 256 bytes on i386 when compiled -Os, slightly more on ARM non-thumb.
 * That might still be a bit large. */

int parsenum(char *s, int len, unsigned int *o)
{
        int first = 0, i;
        int base = 10, m = 1, v;
        char cc;

        /* one can still handle full unsigned words and have a negative multiplier. */
        if ((len > 0) && (s[0] == '-')) {
                first++; m = -1;
        }
        if (len <= first) return -1;

        if (s[first] == '0') {
                if (s[first + 1] == 'x') {base = 16; first += 2;}
                else if (s[first + 1] == 'b') {base = 2; first += 2;}
        }

        for (i = first; (s[i] != ' ') && (s[i] != 0) && (i < len); i++);

        *o = 0;
        i--;
        while (i >= first) {
                /* ASCII is actually pretty darn clever - if you mask out 0x20,
                 * it removes caps and maintains the characters we need. */
                cc = s[i] & 0xdf;

                /* '0'-'9' are 0x30, which are remapped to 0x10 */
                if ((cc >= 0x10) && (cc <= 0x19)) {
                        v = cc - 0x10;
                } else if ((cc >= 'A') && (cc <= 'F')) {
                        v = cc - ('A' - 10);
                } else v = 255;

                if (v >= base) return -1;
                *o += (v * m);
                m *= base;

                i--;
        }

        return 0;
}