Seegras asked

Until Eric S. Raymond turns up in 1990 with this: CRACKER (krak r) n. One who breaks security on a system. Coined c. 1985 by hackers in defense against journalistic misuse of HACKER,
see definition #6. And I ve never heard before of this; so I presume ESR himself decided that people who break into systems are now called by a name which some other group had already applied to themselves. I anyone has some documents referring to this kind of crackers from before 1990 and not from ESR, I d be happy to hear of. And I ve got plenty of documentation on the other crackers , those who crack copyprotection, from 1980 onwards

Does anyone know the answer? Have any thoughts? I penned a few comments below as well but won’t repeat them here. His comment as well as Nona’s reminded me of this brilliant shirt crafted by Mathew Garret.

Here’s a blog post suggesting that anti-depressant drugs such as Prozac may have helped the US mortgage crisis [1]. Apparently such drugs cause poor impulse control, so it wouldn’t be a good idea to attend a house auction while using them. Here’s an interesting idea about lecturing, give 20 minute talks with something else (practical work or group discussion) in between [2]. Michael Lee wants to “capture the power of that strict time limit, the intensity of a well-crafted 20 minutes”. While I’m not sure that a strict time limit is such a great idea. Having talks broken up into sections sounds like it has the potential to offer some benefits. A bible from the 4th century has been found and is being digitised [3]. When the digitisation is complete (next year) it will be published on the net so everyone can see how the bible has changed over the years. Interesting interview with Jim Gray (of MS Research) about storage [4]. It was conducted in 2003 so technology has moved on, but the concepts remain. His ideas for sharing two terabytes of data by using a courier to deliver an NFS or CIFS file server are interesting, the same thing could be done today with five terabytes for a lower cost. Techtarget has a white paper sponsored by Intel about the price/performance of data centers in low-density and high-density designs [5]. I don’t think I’ll ever be in a position to design a data center, but the background information in the paper is very useful. Google has an interesting set of pages describing their efforts to save power in their data centers [6]. They claim to have the most efficient server rooms ever built, and describe how it saves them a lot of money. One of the interesting things that they do is to use evaporative cooling as the primary cooling method. They also have a RE<C (Renewable Energy cheaper than Coal) project [7]. Here’s a Youtube video of an interesting presentation by Andy Thomson (a psychiatrist at the University of Virginia) about male-bonded coalitionary violence [8]. He shows the evidence of it in chimpanzees, humans, and evidence for it being in the common ancestry of chimps and humans (5-6 million years ago). He also shows a link to modern suicide bombing. It’s widely regarded that Cyrus is the fastest IMAP server. Linux-Magazin.de published an article last year comparing Cyrus, UW-IMAP, Dovecot, and Courier and the conclusion is that Courier and Dovecot are the winners [9]. I used Google Translation but the results were not particularly good so I think I missed some of the points that they were trying to make.

• [1] http://www.thedailybeast.com/blogs-and-stories/2008-10-05/did-antidepressants-cause-the-mortgage-crisis/


• [2] http://addisonrd.com/WordPress/2008/09/do-it-first-then-well-talk/


• [3] http://news.bbc.co.uk/2/hi/uk_news/magazine/7651105.stm


• [4] http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=43


• [5] http://go.techtarget.com/r/4692606/8308947


• [6] http://www.google.com/corporate/datacenters/


• [7] http://www.google.org/rec.html


• [8] http://www.youtube.com/watch?v=uuipt15s08c


• [9] http://www.linux-magazin.de/heft_abo/ausgaben/2007/06/auf_der_teststrecke/

Share This

Preface: legal stuff Depending on where you live, use of random open wifi networks might be considered illegal. Although I know of no law in my country against doing this, where you live, things may be different, so educate yourself before following my example. Wifi roaming on the move For the past year I have used my Eee PC on the metro transit bus, as it is the perfect size for this. When I can, I take advantage of open networks to connect back home. In this article I will show how you can actually use such access, will recommend which software works best and will explain how to set it up. So, what can I really do with the net while in motion? How about irc? No kidding! This shell one-liner does the job:

while ! ssh -t 10.9.8.7 'screen -UDr' 2>/dev/null ; do echo -n "." ; sleep .1 ; done

We’re concerned about privacy and security on other people’s networks, so we use ssh. Inside that screen session, keep irssi running for a continuous irc presence. Every 10th of a second, the script tries to resume your session. Once a the net passes by, typing “[Enter]~.” drops you back out to retry again. The row of dots serves as a progress bar. If you want to get fancy, you could replace that with an ASCII ‘spinner’. I leave that as an exercise for the reader. :) Come on, is that really usable? Certainly. As the good folks on #eeepc at irc.freenode.net and #debian-eeepc at irc.oftc.net can attest, even a half dozen brief connections can be enough to provide tech support, rough out some development ideas, or just carry on some friendly chat. If your spouse or housemate is online too, it can even help you make some last-minute grocery-list changes. :) While the script is working, enjoy some offline things such as blogging, reading a cached Planet Debian feed or a PDF book. OK, so what else do I need to make it work? Well, you’ve seen so far we need on a server:

• openssh-server
• screen
• irssi

On the Eee, you should also have:

• openssh-client
• wpasupplicant
• gnome-terminal

But what do I need wpasupplicant for if I only use open networks? Well, wpasupplicant is really handy for fast control of networks in Roaming Mode (as per /usr/share/doc/wpasupplicant/README.modes.gz). A GUI is just too slow. For example, you may need to filter out ‘junk’ open wifi nets: pay-per-use hotspots or nets that hide their name. You’ll not only want a “catch-all” stanza for any open network, but also a number of the most commonly found default network names, e.g.

# Catch-all; associates with any open network:
network= 
     key_mgmt=NONE
 
# Commonly found default network names:
network= 
     ssid="default" 
     key_mgmt=NONE
 
network= 
     ssid="linksys" 
     key_mgmt=NONE
 
# etc. by watching scan_results closely you'll find several more

While the connect script is running, keep a separate tab open in gnome-terminal for wpa_cli. Use ‘disable_network 0’ to drop the catch-all and let the other stanzas kick in and ‘enable_network 0’ after filtering is no longer needed. Isn’t it really slow to get connected? Without some tweaks, yes. But here are a few things I have found by trial and error that help. One issue is that dhclient takes too long to retry, so you drop the delay between retries back to 1 second in /etc/dhcp3/dhclient.conf:

backoff-cutoff 1;
initial-interval 1;

If the signal is very weak, you’ll want the transmit power turned up to the maximum value for your hardware. For the Eee PC 4G this is 50mW, so you set this in /etc/network/interfaces for ath0, your wireless interface:

wireless-txpower 50mW

Finally, while you’re in motion you are constantly leaving no-longer-usable access points behind. The driver needs to discard them as quickly as possible and scan for new ones. So again in /etc/network/interfaces for ath0, you bring the default scanvalid 60 seconds down to 10 with:

pre-up /sbin/iwpriv ath0 scanvalid 10

Conclusion The netbook has changed how we use the net. Now that we can take it everywhere, we either pay through the nose for expensive cell network access or else use the patchy wifi coverage blanketing most urban areas. A few lucky cities have such things as municipal wifi nets, but the rest of us have to scrape what access we can wherever we go. You are now equipped to try this out on the bus. If you find any other tips that can help, I’d love to hear from you.

Via Steve: I had never seen this ad, but apparently it was a classic: The remake: Same actors? Technorati Tags: Wassup, Budweiser, Obama, Election

Via Steve: I had never seen this ad, but apparently it was a classic: The remake: Same actors? Technorati Tags: Wassup, Budweiser, Obama, Election

Since it's apparently en vogue to change one's way these days, I'm now learning Python (by looking at TurboGears and related technologies), using Emacs as my main editor (so far I was using mostly Perl and vim.) But while indenting with vim was often correct but occasionally annoying, I've found the much-touted autoindenting with Emacs disappointing. Yes, indent-region is cool, and if I hit tab on a line it indents it correctly, and using C-J instead of hitting enter also gives the right result. But why do I have to do all this? When I hit enter I want to have the new line at the correct indenting. When I start a line with “</” in a HTML file I want emacs to automatically run indent-for-tab-command on the closing “>” of this tag (or better yet immediately autocomplete the tag, since in XML there is only one tag to close, right?) (Oh, and btw: I've not found much about Python to dislike to date. So while my Emacs use might be just an episode, I might stick with Python as default scripting language for future projects for a while now. I thought about switching to git from hg as well in this “trying new things” effort but I think I'll leave this for later, since I've not had hg annoy me much so far.)

I think Karl hits on all the major points as to why Andrew Keen’s latest post about the demise of open source is wrong. I don’t have much to add except that I suspect that this Internet pundit, like many a pundit, is just seeking a little attention by being controversial as he has nothing of substance to really say. I know I am being sort of controversial here myself but I really do believe there is this strain of punditry whose existence is just to be controversial and garner attention. Hey but at least they keep things interesting right??

I bought my first Apple hardware a number of years ago -- a 400MHz titanium Powerbook. The thing came with Mac OS X preloaded, but it was so slow that it was unusable. I put Debian on it, and was mostly happy with it -- until the titanium case started coming apart. Oh, and the small detail that the built-in wifi reception was so poor that I had to use a PCMCIA card to get a signal in some parts of my house.

But ever since then, we've always had some piece of Apple hardware in active use in our house.

About 7 years ago, my main workstation was a rapidly-aging 600MHz Alpha with -- gasp -- PCI video. It was OK for programming but really awfully slow at anything graphical. I was wanting to get into video editing, and we bought an 800 MHz iMac. The kind with the inverted-bowl base. A nice machine at the time. This was going to be my main workstation.

When it arrived at home, I unpacked it. Terah walked in and said, "Wow, my new computer is cute!" So it became *her* computer, and has been ever since.

It's rather old and is showing its age. Its wifi card died a couple of years ago. The 800MHz CPU is slow with today's websites.

So yesterday, we clicked on the apple and shutdown for the last time. It left her desk, replaced with a Linux desktop with a 20" 1600x1200 LCD (replacing the 15" 1024x768). I had assembled this Linux desktop out of spare parts in our basement, with a 4-year-old Athlon XP CPU. It's still faster than her Core 2 Duo work laptop running Vista, but that's another story.

I put Debian lenny on it. And I've got to say -- wow -- the utility of Debian as a desktop OS for the non-geeky has taken an incredible turn for the better in the last few years. Terah was fine with switching to Linux. I set it up for her -- Firefox for web, Thunderbird for mail, J-Pilot for syncing to her Palm, OpenOffice, gajim, etc.

Her concerns were: having Thunderbird make a nice "whoosh" sound when it successfully finished transmitting an email, having desktop gadgets (I installed screenlets, which I think she likes a lot), and.... I don't think I remember any others.

So now we both run Linux on our desktops.

Oh, and on her laptop, I poked around in the Vista control panels (I must have "authorized it to display this panel" a dozen times, stupid thing), and eventually found a box where I could optimize for visual effects or optimize for performance. I hit optimize for performance, and it transformed its interface into approximately Windows 2000 after a couple of seconds. I think that change made it a lot faster. It's now about as fast as the 25%-as-fast Linux box. I guess that's good for Vista.

So I usually don’t announce my publications on my blog and for various reasons. The main one is that I am more than a little embarrassed that some of them are behind walled gardens (but being I am a junior prof, I am not in a position to negotiate otherwise). Otherwise, some of my pieces are semi-jargony (in the academic sense) and may not be of interest to readers who I think are more geek than academic. Finally, the process of publishing is so slow, so long, and so painful, I try not to think about it, much less write about it, if I can help it. But I decided to announce this
piece , which is on hackers (surprise surprise) as it might be of interest to some readers and because people can download it for free here for the rest of the month (but registration is required ) Co-written with Alex Rex Golub, I am pretty happy to see in print although it is far more academic in its tone, argument, and language than most of everything else I have written. This is in part because the article is more theoretical than ethnographic (hence the journal, Anthropological Theory) and tackles the question of liberalism alongside hacking. It seeks to demonstrate that these can be talked about 1) together and in cultural terms 2) that we we can identify some cohesive elements to hacking and liberalism, in part by placing them in conversation with each other 3) and yet we can also locate plurality and diversity within liberalism and hacking as well. This is a lot to tackle and cover in one piece under 35 pages and I am sure it could have been pulled off better but I think it is is a decent start to thinking about these questions. If you are interested but are allergic to academicalese, sticking to the Introduction, the Hacker Ethical Practice: Three Examples section, and Conclusion, will give you a taste of the arguments while avoiding most of the jargon. The irony of this article is that even if it hits at some pretty theoretical issues, it was provoked by a mundane conversation and disagreement I had with one hacker, Karl Fogel, over another hacker, Kevin Mitnick. After returning from the hacker conference, HOPE, I had dinner with Karl and told him about Kevin Mitnick’s keynote speech, which I found particularity enjoyable and entertaining. After calling Mitnick a hacker, Karl responded with the following: Kevin is not hacker. He is a cracker. Though I think I convinced him that cracker may not be the best word for him (and he convinced me there are differences between hacking, noting perceptively that his primary motivation seemed to be getting access to something he wasn’t allowed to have access to that is, it was more about breaking the rules and the thrill of crossing a social line, than about learning a technical system. ), I decided that I wanted to write a piece that squarely addressed tensions and differences among hackers instead of whitewashing them away as most authors, journalist, and even some hackers do.
Although most of the time, it seems like it is the Karl-type hackers who accuse the Mitnick-type hackers of not being true and authentic, recently I have been in a few situations where the tables were turned. For example, last year I was having coffee with a 2600-type who insisted that hacking on Linux was not hacking at all (not innovative enough, according to his world view). Another example I came across was in a recent Phrack issue where the prophiled hacker, the Unix Terrorist, takes a swipe at (well honestly at everyone and everythin) but when he is talking trash about who is and who is not a hacker, he singles out F/OSS developers:

Linus Torvalds isn’t a hacker! Richard Stallman isn’t a hacker! Niels Provos
isn’t a hacker! Fat/ugly, maybe! Hackers, no! And what is up with
the use of the term “cracker”? As far as I’m concerned, that term
applies to people that bypass copyright protection mechanisms.
Vladimir Levin? HACKER. phiber optik? HACKER. Kevin Mitnick? OK,
maybe a gay/bad one, but still WAS a “hacker.” Hope that’s clear.

Of course, one can play the game of defining the authentic hacking (and it makes sense for many to do this!) but my interest as an anthropologist has never been to draw a bright and clear boundary between good hackers and bad hackers. or “real and fake hackers,” but instead to describe and grapple with the tension points and internal ambiguities among hackers (my whole course is designed around this theme, in fact). This is not to say that anything goes in the world of hacking (that is, I don’t consider any computer break in a hack; I often just call it a crime) but if there is a group of people calling themselves hackers and thinking to some degree of the ethical implications of their actions, as an anthropologist, this is enough “social evidence” to start asking some questions about the political and cultural significance of their actions.

For a minute, I’d like to think about The Announcement in terms of problems and solutions. Problem: We don’t have enough non-developing contributors in Debian
Solution in The Announcement: Give them special, official, statuses in the Debian community, so they are rewarded for their work.
Alternate solution: Are they really looking forward this status? Aren’t we just thinking that they are just as power-hungry as we are? Last time I checked, the Debian community wasn’t really welcoming non-developers. It isn’t a problem of official status. We have to work on ourselves to make Debian a better place to be for non-developing contributors. Also, giving those people a second-class citizenship, that won’t be widely recognized — “Debian Member” instead of “Debian Developer”, isn’t going to help. (or even worse, “Debian Contributor”, which doesn’t give any right except an email address). Problem: We have a trust and security problem. It’s difficult to give upload rights and access to Debian machines to more than 1000 people, with some of them not being active anymore, or not having much experience with security (in the case of non-developing contributors).
Solution in The Announcement: Remove rights based on classes of developers, so the group of people having full access stays within manageable boundaries.
Alternate solution: Have fine-grained control on who can do want. Problem: DMs can’t get access to Debian resources because their keys aren’t managed by the Debian keyring team, but by another team.
Solution in The Announcement: Keyring managers will take care of the Debian Maintainers keyring too. In the past, the keyring managers were the cause for huge delays in the NM process. It has improved a lot recently, but it doesn’t mean that it will always be like that.
Alternate solution: Make the DM keyring team, the keyring managers, and DSA, work together on a solution. it doesn’t sound impossible. If that’s necessary, merge the DM keyring team and the keyring managers. Problem: DM was done without the blessing of most of the members of the loosely defined group of powerful DDs (sometimes described as “cabal”).
Solution in The Announcement: Drop it, replace it with something very similar, but originating from the cabal.
Alternate solution: Why not keep it? Problem: Clueless DDs advocate clueless contributors for DMs. Then those DMs upload crap to the archive. (Note: I don’t necessarily agree with that problem, that’s just a problem that the announcement tries to solve)
Solution in The Announcement: Require answering a few questions before becoming a DM. Remove the right for every DD to decide which DM can upload which package. Give that control only to the NM committee.
Alternate solution: If we can’t trust one DD to take the good decision about advocating someone for DM, we could require that each person needs to be advocated by two different DDs. Or three, four, five. Asking the DM to answer a few questions, whose answers he can probably get by asking around on IRC, is not going to improve the average level of our DMs or DDs.

---

I believe that there are real problems that need to be solved, but that the decisions announced don’t solve the real underlying problem. Here is what I’d like to see:

• Fine-grained access control for each DD or DM or …:
  This would allow people to have specific rights inside Debian, like:

• Right to login on each debian.org host (a per-host switch)
• Right to upload packages for which the person is Maintainer or Uploader
• Right to upload any package
• Right to vote

All rights would default to “NO”. DDs would be allowed to change their rights for everything, while DMs would only be allowed to change specific rights. Of course, we need a secure way to change rights (HTTPS+confirmation using GPG, like the current “sudo password” thing?). But that would help with the security problem (you wouldn’t have access to all Debian hosts without enabling it). In fact, we already have that: many hosts require a switch to be enabled in LDAP before you can login, and we have tons of Unix groups to restrict access to specific areas of our infrastructure. I’m just proposing to extend that to basically everything, and to allow people to grant themselves some rights without going through DSA.

Modified NM process for non-developing contributors, that would still include many P&P and T&S questions, but would give “Debian Developer” status without any upload rights. That way, non-developing contributor would have an official status, and will still be able to write “Debian Developer” in their resume. Giving a different status to those people just because we don’t think that they should have the right to upload any package doesn’t feel right.

Is that enough? Probably not. We need to be more welcoming towards non-developing contributors, which is a social problem, not a technical one. But we are not going to solve that in a GR.

The only plausible result from this RNC mailing, I think, is increased fundraising for Obama over the next few days: For the nearsighted, the front of the mailing says “Terrorists Don’t Care Who They Hurt” and inside: “Why Should We Care What They Have to Say? … Barack Obama. Not Who You Think He Is.” I would be surprised if the Obama campaign doesn’t get a measurable bump in donations for every mailing like this. What I really wonder is how intelligent Republican party members tolerate this sort of thing. Aside from Colin Powell, are other high-IQ Republicans voting against their party because of these tactics? Or do they just believe any means justify the ends? My pet theory as to why these attacks are useless (at best) to the GOP is that they don’t resonate with anything the voters are seeing. The GOP implies Obama is a muslim terrorist who is inexperienced and risky and also an extreme liberal/socialist left-winger (I haven’t heard “communist” yet from the mainstream), while what the electorate sees in the debates, ads, and campaign appearances is an uncannily steady, balanced, articulate individual who comes across as a moderate on most issues (note Obama’s theme of returning to Reagan-era taxation levels!) At least with the “flip-flopper” attacks (and maybe even the Swift-Boat attacks) on John Kerry, there was something people could see that somewhat corresponded with the attacks, even if the underlying facts didn’t actually pan out. Here, the chasm between the nature of the attacks and the visible target is so great, they could only help energize those who are already hard-core partisans. The lesson here is that if you want to launch misleading, baseless attacks against your opponent, at least find some kernel of truth to base them on. On a similar note, I agree with Aaron Swartz that ACORN deserves our financial support. Finally, I predict a bunch of astroturf comments to this blog entry. I won’t bother to respond if the comments fail to say anything intelligible. Technorati Tags: Politics, Election, Obama, McCain, Terrorism, ACORN

The only plausible result from this RNC mailing, I think, is increased fundraising for Obama over the next few days: For the nearsighted, the front of the mailing says “Terrorists Don’t Care Who They Hurt” and inside: “Why Should We Care What They Have to Say? … Barack Obama. Not Who You Think He Is.” I would be surprised if the Obama campaign doesn’t get a measurable bump in donations for every mailing like this. What I really wonder is how intelligent Republican party members tolerate this sort of thing. Aside from Colin Powell, are other high-IQ Republicans voting against their party because of these tactics? Or do they just believe any means justify the ends? My pet theory as to why these attacks are useless (at best) to the GOP is that they don’t resonate with anything the voters are seeing. The GOP implies Obama is a muslim terrorist who is inexperienced and risky and also an extreme liberal/socialist left-winger (I haven’t heard “communist” yet from the mainstream), while what the electorate sees in the debates, ads, and campaign appearances is an uncannily steady, balanced, articulate individual who comes across as a moderate on most issues (note Obama’s theme of returning to Reagan-era taxation levels!) At least with the “flip-flopper” attacks (and maybe even the Swift-Boat attacks) on John Kerry, there was something people could see that somewhat corresponded with the attacks, even if the underlying facts didn’t actually pan out. Here, the chasm between the nature of the attacks and the visible target is so great, they could only help energize those who are already hard-core partisans. The lesson here is that if you want to launch misleading, baseless attacks against your opponent, at least find some kernel of truth to base them on. On a similar note, I agree with Aaron Swartz that ACORN deserves our financial support. Finally, I predict a bunch of astroturf comments to this blog entry. I won’t bother to respond if the comments fail to say anything intelligible. Technorati Tags: Politics, Election, Obama, McCain, Terrorism, ACORN

I've just started a new job, so I decided to take a few days holiday in between and work on something that's been on my todo list for way too long now -- making the debian-installer work on the D-Link DNS-323. After a couple of days of work, I've just finished off the install of Debian on my DNS-323, which I initiated by loading a firmware image into the web interface of the stock firmware, and then SSHing into the machine at the appropriate moment. What this means is that anyone with a DNS-323 can install Debian on it. I think that's worthy of a small, quiet "woo hoo!"... Looking back now, it seems to have been a fairly simple and straightforward operation, but I can remember that it didn't look so simple when I started a week ago. So, in the interests of perhaps short-cutting someone else's adventure into the world of d-i hacking, I'm writing everything up while it's fresh in my mind (the benefits of being on holidays -- plenty of time to write long blog posts). Alternately, if anyone has a random device they'd like to see d-i on but doesn't have the inclination to do it themselves, feel free to send me one and I'll do it for you. Before I begin, I've got a few "shout outs" (I think that's what the cool kids are calling it these days) to people who've helped me along the way. First off, Martin Michlmayr has answered innumerable dumb questions from me, and I think wrote most of the parts of d-i that I've extended -- it's fair to say that I'd have had no hope of doing this without him. Thanks also to the people in #debian-boot and #debian-arm for answering questions and putting up with my frequent bouts of self-congratulation whenever I passed the most miniscule milestone. Finally, everyone who has put work into d-i has my thanks, too -- it's not perfect, but it's a damn sight better (both to use and also to hack on) than any other installer I've ever met. So, without further ado, off we go... Work out how to get a console Unless you are a guru of unbelievable skill, you will undoubtedly not do everything quite perfectly the first time, and you'll want to see the kernel/init boot messages, and maybe in some cases try some investigation and diagnostic work. For that, you're going to have to have some sort of console access. If the device doesn't have a full screen/keyboard thing going on, the chances are you'll almost certainly end up with a serial console. A few devices have a network management thingo that will give you a console, usually over VNC or some sort of horrid Java applet, but I've only ever encountered that in rackmount servers, which have a keyboard/video interface anyway... In theory, I suppose, the kernel could provide a network console, but I've never heard of such a thing being attempted, and Google is not helping me out. I might add that to the todo list as a future hacking project... On the DNS-323, it was a serial console that was needed. Like a lot of the embedded devices I've seen, it didn't quite talk RS-232, so I needed an adapter (I got a TTL-232R-3V3 USB-to-3.3v-serial adapter from a local electronics supply place, which worked perfectly with Linux as soon as I plugged it in). I needed to solder a few wires to a connecter inside, and connect that up to the USB doohickey, but it all came good in the end. The chances are someone's done a similar job for your device of choice, so a search for things like "devicename serial console" will almost certainly pay off. Work out how to load and boot a kernel/initrd Your development work will involve booting weird kernels and initial ramdisks to make everything work; you need some way of stuffing those into the device and booting from them. Everything has a boot loader of one sort or another; working out what you've got and how to make it sing and dance is the ultimate quest here. How this is done will vary greatly from device to device; the WRT-54GL, for example, waits for a tftp connection for a couple of seconds on startup, which you can use to send a new firmware; many other devices have a boot loader that you have to explicitly control (via the console), but it will make a tftp connection out to another machine if you ask it to. Some devices you just need to load the data in via serial cable (at 115200bps it's bearable; at the 9600bps I've heard some devices work at, it would be tres painful). The DNS-323 runs uBoot as the boot loader, which will do a tftp request by default. However, D-link, or Marvell, or someone in the decision-making chain for this thing decided to knobble it and removed most of the useful commands, so sending the thing via serial port is the only option. Since writing to flash takes a pile of extra time, I found (eventually) that you can just load the data into RAM somewhere and boot from there, without needing to write it to flash (also handy to avoid wasting precious write cycles), since you can tell uBoot to boot a kernel located anywhere in the address space. Obviously you need to reload the kernel/initrd on every boot if you don't write it to flash, so if you've got a "stable" kernel or initrd that you think you'll be using for a while (when you're testing the other item) you should flash it then. One note on uBoot, that took me far too long to work out -- you can't just stuff a kernel fresh off the Makefile in and assume it'll work -- uBoot needs a special header prepended that tells it all about what you're loading (architecture, file type, compression method, etc). You "wrap" a file in this uBoot header with the "mkimage" command (in the uboot-mkimage package in Debian). Incidentally, if you need to remove the uBoot bits from a file, just strip the first 64 bytes off -- that's all the uBoot header is, so something like this will do nicely:

 dd if=file.uboot of=file bs=64 skip=1

A final uBoot warning: it's fairly important to specify a "load address" for the files; if you get them wrong, your kernel and initrd may or may not boot (I never quite got the hang of why some wrong values worked and some didn't). If your device uses uBoot, and you have the ability to extract the uBoot-enabled kernel and initrd from a vendor-provided firmware image, you can use mkimage -l to inspect what all the values need to be for your own kernels and initrds. Just stick with them. Does Debian support your hardware? Obviously, if you want to run Debian on something, Debian has to support that hardware. The easiest way to test this out is to try an install. For this, you'll need to retrieve an appropriate kernel and initrd pair for the installer. Some arches, like i386 and amd64, only have one kernel and initrd for the installer, so you just have to choose if you're going to netboot, or do a full CD install, or whatever. Other arches, though, like arm, have subtly different images for different machines. There are two reasons they vary: firstly, they often need to split into subarches, where they all share a general CPU architecture but there are enough differences in the hardware that they're not all supportable by the same kernel. At a more fine-grained level some different machines of the same sub-architecture need differently formatted firmware images to boot. On ARM, in particular, it's pretty common to need to prepend a "device ID" to the kernel image so that the kernel knows what sort of machine it's booting on, which means that every machine typically needs it's own kernel image, regardless of any other issues with firmware formats. Choosing the sub-architecture should be relatively straightforward, if you know much about the machine you're targetting. Picking a machine type can be a bit harder, but again, if you know what your boot loader needs, it shouldn't be too hard to find a kernel/initrd from the existing machines in your subarch that you can mangle to fit. Load up your kernel/initrd into the device, boot it, and see how far it gets. You might get lucky, and the kernel inits, your hard drives are detected, your NIC is initialised, and you're off and running without further ado. Or you might not be so lucky. The worst case is that the kernel doesn't even get as far as loading the initrd -- it might not print anything at all, or the kernel might hang part way through the boot. This is likely to require a fair amount of debugging fun, as initial boot failures get a bit tricky. A better situation is where the kernel boots OK, and d-i starts, but something in the install process falls over. This can either be a kernel/driver problem, or a d-i problem. Either way, since d-i has started, you're likely to be able to get a shell and do some debugging. In order to make d-i work, you need to have somewhere to install to (disks, usually) and a source of packages to install from (CD/DVD if you're on a suitably large device, or the network otherwise). These are the two key ingredients you need; most everything else is stuff that ranges between "nice to have" and "critical" for operational purposes, but which has absolutely zero impact on your ability to do the install, so we'll ignore it for now. For the DNS-323, I had a few kernel problems (which I'd been warned about by Martin before I started) -- the NIC wasn't initialised with it's MAC address, which meant it was running around my Ethernet screaming "I am 00:00:00:00:00:00! Ph33r m3!", and the SATA controller just didn't seem to exist at all. These were kinda critical to doing an install, so it was time to get hacking to make those work. There were also a couple of parts of d-i that needed tweaking -- the preseeding code didn't support the device, and I needed to package a tool to build a "complete" uploadable firmware image and teach d-i how to use it. Apart from that, though, things were looking pretty good. Make the Debian kernel support your hardware Once you've worked out what hardware you need to make work, you need to dig into the kernel and fix it. Sometimes, if you're really lucky, a kernel version newer than the one currently in Debian has better support for something, and you can backport the fix / feature improvement. Other times, there's something similar already in the kernel for a different device and you can crib off that (I did this extensively for my little fixes). Then there's the "ask an expert" school, where you find someone who knows what they're on about and pick their brain (I did a bit of that, too). Finally, there's plain old "research and development", for which there are piles of documentation already out there. My changes for the DNS-323 came to 121 added lines and 16 deleted lines, most of which was cribbed-and-tweaked from other parts of the kernel. I might have written 10-20 lines of code "from scratch". It's not always scary-hard. Cross-compiling your own kernel One thing that I think needs mentioning in the kernel hacking department is cross-compiling a modified kernel for testing purposes. Chances are your main workstation has a lot more grunt (and build tools) than whatever you're trying to get Debian onto, so cross-compilation is the way to go. You need to first grab a copy of the source you want to build (from apt-get source linux-image-blahdiblah, or a release tarball, or Linus' git repo, it doesn't really matter) and a cross-compilation toolchain. For my cross-compilation toolchain, I just added this to my sources.list:

 deb http://www.emdebian.org/debian/ unstable main

then I ran apt-get update, and installed these packages:

	binutils-arm-linux-gnueabi gcc-4.1-arm-linux-gnueabi
	gcc-4.3-arm-linux-gnueabi-base libc6-dev-armel-cross

Kudos to the emdebian team for making that such an utterly painless exercise, by the way -- the days of needing to faff round with gcc sources to get a cross-compilation toolchain are apparently over. Once you've got a source tree and a cross-compiler available, you can run any of the usual kernel make commands (like make zImage or make oldconfig), as long as you've got a couple of make variables defined. In my case, I used:

 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-

ARCH tells the kernel what architecture to build for (useful in all make commands because not all arches have the same config options in make menuconfig, for example) and CROSS_COMPILE tells the build system what to prefix the calls to gcc, ld and such with (if you installed the same cross-compiler packages as I did, you'll find it installs files like /usr/bin/arm-linux-gnueabi-gcc, so you can ls /usr/bin/*gcc to find out what you'll need for the CROSS_COMPILE setting). Hack d-i to make things work In addition to tweaking the kernel, it's quite possible that the internals of d-i might need some tuning. It's possible that d-i might need to be "taught" to recognise the hardware in your device, or you'll need to extend some aspect of the installation process to complete the installation. In order to hack d-i, you need to know a bit about how it works and how it is structured, so let's run through that first. The entireity of d-i is based around udebs, which are packages of the same format as "real" debs, but which have been built differently (against a small libc, for instance) and have had everything that isn't absolutely necessary (docs, non-essential scripts, extra functionality, etc) stripped out of them to create the smallest possible packages. There are a variety of different udebs -- most are derived from otherwise normal, law-abiding citizens of the archive, like busybox (basic unix utilities like cp and ls), the shell that's used in the installer, parted, various libraries, and so on. Others are "special", and have no big brother in the archive. These are mostly "task" udebs, that define what actually happens in the installer. When they're "installed", they have special fields in the package metadata that define where in the install sequence they go, and they end up on the menu you see if your installation goes a bit pear-shaped. The tricky thing about udebs is that, as small as they are, there's too many of them to be able to have them all available when the system first boots, so even the "setup" of the installation gets done in several stages. First, the kernel and initrd boot. The initrd contains just enough stuff to get access to the rest of the udebs, and nothing else. Even this early stage is built from udebs -- there's lists of what goes into the initrd for various architectures and flavours of installer under installer/build/pkg-list in the d-i SVN. If you need an extra udeb in your initrd, that's the place to specify it. Once the initrd has gotten access to a source of packages (off a CD, over the network, telepathy, whatever) it can drag the rest of the packages it needs from there. Space is still an issue at this point, though -- there's no diskspace yet to put anything onto, so everything needs to fit into a ramdisk. Don't go loading anything you don't need. The packages loaded at this stage are what defines most of the steps that will be done for the rest of the install, so once all those extra udebs are loaded, the remainder of the install kicks off and does it's thing. Different architectures and install methods have different requirements, too, which complicates matters. For example, when you're installing on a regular PC with screen/keyboard, you can guide the install using that. However, if you've got no screen, how can you control the install? There's serial consoles, but requiring everyone to void the warranty (more) on their little embedded doodad by installing a serial console cable to install Debian isn't so hot. So, lacking a terminal, how do you control the install? Well, on install flavours for devices that might be in this situation, you can SSH into the installer and complete it that way. That feature is, like everything else, provided in a udeb -- called network-console, as it happens. But what IP address do you connect to, and what network settings does the device use? Again, without a console you can't configure your network, and not everyone has a DHCP server (and even fewer people have a DHCP server that will hand out an address that they'll know in advance, or be able to find out). So, there's a udeb (called oldsys-preseed) that does it's best to configure your network based on the settings already in the nvram for your device. In short, there's a lot of tricky, well-thought-out shit going on inside d-i, and you might have to deal with a little bit of it. The nice thing is that by now I expect most of the really hard problems have been solved, so with a bit of luck you'll only ever have to do minor tweaking. In general, all of the packages that are "d-i specific" live in packages in the d-i SVN. If you need to modify a udeb, you need to rebuild it and put it in installer/build/localudebs/ (creating it first if need be) and every time you change it, you need to delete installer/build/apt.udeb/cache/. To give a concrete example (from the ever-present DNS-323), I had to modify oldsys-preseed so that it would get the details from the nvram that the stock firmware uses to configure itself. This, in turn, required that the minix-modules udeb be included in the initrd, because the DNS-323's nvram is actually a small minix partition stored in flash. Painfully, this required some more hacking, because the armel d-i kernel wasn't configured to generate minix-modules. That might need some explanation... Since building the kernel is a fairly massive undertaking, CPU-wise, instead of building all the udebs from scratch there's a package called kernel-wedge to split a real linux-image package into lots of little udebs. There's a separate source package for each architecture, linux-kernel-di-$ARCH-2.6, that contains the configuration data for kernel-wedge to specify what udebs need to be built, and what goes into each of them. A small tweak to the armel package and voila! I had a minix-modules udeb to include in the initrd. With the config stuff I'd done in the d-i build itself and my changes to oldsys-preseed, we were done with d-i. Tell d-i how to build your bootable artifacts If your device needs a "different" install image from other similar devices, you need to write some makefile rules to build those files. Look under the installer/build/config/$ARCH/ directory to see the various rules files available. I had to package a new tool to create uploadable firmware images for the DNS-323, along with adding a rule to use that tool to build images. None of it was particularly difficult. Polish the diamond Getting d-i working is only part of the battle; it's quite likely that there will be other hardware in the machine that needs to be supported. This could involve kernel-level stuff to interface to the hardware, or userland tools to manage the hardware. There's several bits in the DNS-323 that still need work; I can't control the LEDs on the front panel, nor the fan, and I can't use the on-board temperature sensors yet. But, I do have Debian running on the thing, which is what I was shooting for. Examples If you're interested in exactly what I did, there are a number of bugs in the BTS that contain the patches I made:

• #502821: oldsys-preseed changes to take existing network config from NVRAM;
• #502936: build a minix modules package for the armel d-i kernel;
• #503040: d-i core changes to build firmware images for the DNS-323;
• #503172: kernel patches to support the SATA controller and NIC better.

Lenny is the codename for the next release of debian, which will be debian 5.0 formally. For the first time that I can remember, debian will fit on one disk. OK, so it’s a blu-ray disk (BD), but I’m sure it will be a selling point to some people. The announcement goes into some more detail about the implications for data transfer and mirror sizes, as well as noting that it stresses genisoimage beyond breaking point. Before the release, there’s the small matter of about 200 bugs which we need to fix. If you can help, please do. One prickly problem in some of the bugs is that a second debian release in a row is looking like it will allow violations of the Debian Free Software Guidelines into the release. (I don’t think all of the listed example bugs are violations, but some are). My main question about the firmware ones remains the same as two years ago:-

“I think the idea that refusing to ship non-free firmware in main will strengthen demand for free firmware is worthy of consideration. Debian helps users to take control of their operating system. Increasing the demand for free firmware might also help users to take control of their hardware, or at least highlight that there’s this crap which their operating system uses to support their hardware but doesn’t have its normal freedoms.” “However, I’m undecided whether it’s a good idea to exclude them from the distribution CDs and so on. How big is the problem of vital hardware which won’t work without firmware being copied to it? Should we split non-free into non-free-hardware and non-free, allowing non-free-hardware packages onto the CDs?”

Ben’s technical blog: For those who care about firmware is tracking some of the hardware, but I don’t own any of the untested ones. That’s not surprising: I’ve been trying to avoid closed firmware for a few years now. Debian bug #502959 discusses how one of the key debian project machines is affected. There’s a nice suggestion of using some of the project’s $64,000 to buy some hardware that’s fully supported by free software, but the bug has been closed by Peter Palfrader with the message “go screw yourselves and do something useful, like find a bridge”. Yikes. Is there less vital hardware now than two years ago? Can the patches provided really not be included?

One month with Emacs and counting - Part 1 Straight to the point: since mid September I've been using Emacs, trying to evaluate whether I was willing to switch from Vim to it. Yup, that's true, me (user of Vim since the day I've started using GNU/Linux 10 years ago, (not so) active maintainer in Debian of vim and related packages, author of some popular Vim extensions and of vim-addon-manager) it's considering switching to Emacs. What is worse is that I've de facto already switched. May jamessan forgive me. OK, that was the hardest part to write, now ... This choice will have an impact on me: partly because I'm quite sure several fellow DDs will start making fun of this story , and partly because as many geeks I've always had strong opinions on the editor war. Switching side ain't easy. Hence, I've decided to write a small (2-3) series of blog posts on the issue, to future memory. The post you are reading is about why, since a few months ago, I wasn't willing to give Emacs a try, and how I've changed my mind. Why I wasn't willing to give Emacs a try, but then changed my mind I love knowing tools which can improve my workflow, no matter the task. Editors happen to be at the intersection of many tasks, hence knowing well his own editor and feeling satisfied about it is quite important. This is even more so for free software hackers which, for a reason or another, happen to use the very same editor for a lot of different tasks; in my case: programming, conf file hacking (i.e., playing the sysadm role), mail writing, and everything in between. I've started using vi on Solaris around 1998, then switched to Vim starting from version 4.0, and then followed all its releases up to 7.0. I consider my "Vim karma" to be quite hight and I've delivered several talks about using Vim for LUGs and other free software-related events. Still, I've always been hit bit several minor nuisances and glitches of Vim which couldn't be fixed by simple configuration tuning or add-on implementations (more on this in a future post). In the quest for the perfect workflow, those glitches have made me try several times other editors hoping for more satisfying work environments. Of course Emacs was one of them, which I've tried repeatedly during the years; the last time was circa 2006. For one reason or another, after a few days of experiments, I've always decided to give up with it. Why? Various reasons, listed below, together with an explanation of what (I think) has changed since then.

1. Poor Unicode/multibyte support. Support for whatever Unicode encoding was close to null. It was not available in the legacy editor, and you had to use something called MULE, to be specifically enabled. That was so 60's, and rather hard to use. Now (apparently starting from Emacs 22.1, June 2007) finally you have built-in Unicode support and the needed two variables for setting the input encoding and the file encoding, which is basically all you need. Looks easy once you have it ...
2. Lack of "modern" UI toolkit support. Yes, I do live in a console and invoke my editor from it, but nevertheless for long coding sessions I do also love having a nice GTK+ window containing my editor using settings which smoothly integrated with the graphical settings of my desktop environment. Maybe I'm getting old, maybe GNOME has changed my perceptions, but why the heck I had to tolerate different monospace fonts in my gnome-terminal wrt my GUI editor I never understood. Firing up Emacs was like getting back in time of 15 years, and if a geek having a maximized terminal on most of its workspaces had this feeling, then something was really wrong. This has changed: starting again from Emacs 22.1, the editor has frown support for that "bleeding edge" technology called GTK+. Finally you can use Pango font faces and avoid the time travel feeling when switching from a terminal to your GUI.
3. "Dead upstream" syndrome. As we all know by experience, choosing a free software product is not only a matter of evaluating bugs and features, there are other environmental factors. A notable example is how active upstream is. A few of us will use a product affected by the "dead upstream" syndrome. That's exactly what I was feeling about Emacs. The first argument I can offer to back that feeling is again the Emacs release history (noted that "small" hole between 2001 and 2007? Rest In Peace release early, release often ...). The second argument is the bug tracking system: there was none, bug discussions happened only on the development mailing list and the bug tracker was a text file on CVS! (Yes, Vim doesn't have a proper BTS either, but I was looking for reasons to switch from it and hence looking for something better in several respects.) That has changed completely, as I discovered only at this year DebConf thanks to gismo. 2007 has enjoyed 1 Emacs release and 2008 already two. They do have a BTS now and guess what? is dear old debbugs. According to my first experiences as Emacs bug reported the maintainers are very reactive and also friendly in dealing with bug reporters. Finally, also keeping up with snapshot releases in Debian is entirely trivial, thanks to Romain's repository.
4. Poor performances & memory consumption. This goes in the direction of probably the most popular joke used by Vim zealots in the editor war: Emacs is a nice operating system, but lacks a good editor, or something such. In the past I had the impression that starting Emacs was really slow and that generally the memory footprint was too high to be acceptable. You know what: starting a full-blown gvim with a good deals of add-ons (and I used quite a lot of them, that's why vim-addon-manager was born) is not that faster. And on the contrary, firing up an emacsclient is way faster than starting up a new gvim instance. Regarding memory consumption Emacs is still "gaining" the battle. Still, one has to keep in mind the different workflow: with Vim you are encouraged to enter and exit the editor (not without drawbacks, as I'll discuss in a future post), while with Emacs you always use the same one. It turns out that via emacsclient the resulting feeling is the same as having multiple editors (as you can fire them up as separate windows or in separate consoles), still sharing all user memory. A final comment on memory consumption while looking at my top sorted by decreasing RSS memory: the top process is xulrunner (from the browser) with 356Mb, then Xorg (159M), pidgin (128Mb !!!!), trackerd, gnome-terminal, gnome-panel, ..., Emacs shows up with 51 Mb at the 7th position. Yes, it is not the thinnest editor in the world, but on average machine it doesn't really matter at all.

In the next post: how to switch from Vim to Emacs, without loosing your mental sanity. (Whether I did succeed wrt sanity is up to the reader to judge.)

So you put off buying a high-def TV for years, because you weren’t sure they had gotten all the standards right. You recently gave in, thinking that the coming shut-off of analog broadcast TV in February meant that they had to have their technology figured out by now. Of course, you were wrong:

CableCARD devices have generally supported only one-way access to cable systems, but their long, winding journey toward full two-way communications is finally coming to an end. Panasonic has announced that it is at last shipping new HDTVs enabled with tru2way technology to the two US markets where they can actually be used.

So what’s the main thing you’re supposed to get with tru2way?

This means that you can walk out of a retail store with a tru2way-enabled HDTV, plug it in at home, and have immediate access to basic features like an on-screen guide and on-demand content.

In other words, we are just now starting to see HDTVs that can just plug into the cable jack and work, without an add-on cable box and all the limitations that implies, right? Well, not really.

All tru2way-compatible devices will have a CableCARD slot built into them to facilitate the decryption of protected content, though details are still sketchy as to how this system will work with devices like PVRs. Physical CableCARDs will apparently not be needed to access basic two-way services and non-encrypted channels.

Meaning that, in order to get anything you can’t get already with broadcast TV (”non-encrypted”), you still need a cable company tech to come out and install the CableCARD. And they don’t know how all of this will integrate with the new video recorders like TiVo. Why is this so hard? It’s producer paranoia. If they don’t play these games, you might watch some show for free, or share it so others can watch it for free, instead of… well, watching it for free live. And you might cut the commercials out, instead of… cutting the commercials out by getting up for more chips during the commercial breaks. (But that’s stealing, so you shouldn’t do that either.) Our family keeps edging closer to deciding to get a HDTV. But then I see stuff like this, and notice that the old tube TV still works fine…

I’m not sure which is the second-largest of the projects supported by Software in the Public Interest, but I thought that OpenOffice.org was up there with them. It’s been a bit of a surprise to me that SPI hasn’t done more for them since they joined back in March: only about $1,000 has been donated that way, none spent and I’ve not noticed their liaison being very active yet. Following the release of OpenOffice.org 3.0, I took a bit of a closer look. Stuff Michael Meeks is doing: Measuring the true success of OpenOffice.org suggests that the project is much smaller than I thought:

“In a healthy project we would expect to see a large number of volunteer developers involved, in addition - we would expect to see a large number of peer companies contributing to the common code pool; we do not see this in OpenOffice.org. Indeed, quite the opposite we appear to have the lowest number of active developers on OO.o since records began: 24, this contrasts negatively with Linux’s recent low of 160+. Even spun in the most positive way, OO.o is at best stagnating from a development perspective. “

OpenOffice.org is a project that produces something I don’t use much, but I recognise the significance of it. I’ve looked at contributing a couple of times in the past (nothing major, just bug reports and offers of help), but got utterly lost in the maze of websites and copious verbose descriptions written in management buzzspeak. (I spotted a “Report a Bug” link taking me to a page titled “Submit an Issue” for example.) Looking again now, OOo doesn’t seem much easier to navigate. I did find that SPI doesn’t appear to be listed on their donation page yet, which probably explains the low donation amount. Another confusing thing: they don’t use bugzilla, but a less accessible fork called Issue Tracker. Even simple contributions seemed to want multiple registrations to websites, mailing lists and whatnot - that seemed to contradict a claim that “Joining OpenOffice.org is purely optional” - and a confused email question to an address listed on the website got a rejection/error in reply. I’m sorry to say that I got confused, discouraged and moved onto other, easier things that I’d use more. Anyone else looked at contributing? How did it go for you? Anyone understand how this associated project works?

Some drivers in Linux include "firmware" - code that runs on the device the driver deals with, not the main processors in the system. Most of this is in a binary or equivalent form, which is probably not the form that it was originally written in. This makes it non-free by Debian's standards, an issue which has led to much argument around previous releases and has blown up once again. The good news is that kernel developers are making a continuing effort to separate this from the driver code. I've collected together the patches that do this and written 2 of my own, which appear to cover all the remaining sourceless firmware. But I was only able to test one of these drivers (radeon) - the rest is up to you. Affected drivers

Driver	Hardware which requires firmware	Bug report	Change made
cassini	Sun "Cassini" Ethernet controllers with "Neptune" PHY	498631	removed
dabusb	BayCom DAB-USB radio receivers	502663	moved to firmware-dabusb
e100	Intel PRO/100 Ethernet controllers with PCI revision 8, 9, 15 or 16 or built into ICH6 or ICH7 (LAN-on-motherboard)	494308	moved to firmware-e100
kaweth	Kawasaki LSI USB Ethernet controllers	502665	removed
mga	Matrox G200, G400, G450(?) and G550 graphics controllers, 3D acceleration only	502666	moved to firmware-matrox
qla1280	QLogic QLA1XXX SCSI controllers	502667	moved to firmware-qlogic
r128	ATI Rage 128 graphics controllers, 3D acceleration only	494007	moved to firmware-ati
starfire	Adaptec DuraLAN aka Starfire Ethernet controllers	501152	moved to firmware-adaptec
tehuti	Tehuti Ethernet controllers	501153	moved to firmware-tehuti
typhoon	3Com Typhoon (3CR990) Ethernet controllers	502669	moved to firmware-3com
whiteheat	ConnectTech WhiteHEAT USB serial adapters	502668	removed

How to test

1. Download and install the linux-source package from http://people.debian.org/~benh/firmware-removal/. There is a signed .changes file there that you can use to verify the package.
2. Build and install a kernel from that source (you should probably use make-kpkg).
3. Boot the kernel. Check that the driver fails cleanly: it should not crash, and there should be a useful error message in /var/log/messages
4. Download and install the relevant firmware package, if available. These are available from the same place as the linux-source package.
5. Reboot or reload the driver. Check that the driver is now working.
6. Add your results to the bug report as shown above.

Firmware that is removed Do you depend on the drivers for which I have removed the firmware? Do you have contacts with the vendors who might be able to help relicence it? Please send mail to the bug report. Update I checked my email and found a response from ConnectTech; the WhiteHEAT firmware will probably be clear to package in firmware-nonfree. There is no need for anyone else to contact them.

I am all for models and examples, and well, Nerd Girls, is such a web portal meant to celebrate “smart-girl individuality that???s revolutionizing our future.” And they “want to encourage other girls to change their world through Science, Technology, Engineering and Math, while embracing their feminine power.” That message is all good and fine but the profile page is just a little too homogeneous and “made up” and actually just looks fake as fake can be (and what is UP with those dumb glasses they are all wearing?!). Sorry to say this, but all those “chics” look like they are fake nerds and are really models for Seventeen magazine or soft-porn movies. Is Nerd Girls a joke? Or is it real and just not for Ugly (or regularly looking) Nerd Girls? update
[h0mee] lol
[h0mee] actually what it really reminds me of
[h0mee] are those inspirational posters you see in high school meant to inspire students to study harder
[biella] like this one update again (sorry, the comments on my irc channel are just too good to ignore: [Atala] lol one of my friends just said the site seems like a thought experiment on what would happen if MTV bought Bitch magazine.
[rex] EXACTLY