Well, it happened.  First and foremost, I’ve always tried to make my blog interesting to readers interested in technology & energy, and in the process I’ve sometimes linked out to relevent products on Amazon, to make me a little beer money.  I’ve tried not to be too annoying or gratuitous about it, but it did help a little to offset the ISP charges etc.  But today I got this email:

We are writing from the Amazon Associates Program to notify you that your Associates account will be closed and your Amazon Services LLC Associates Program Operating Agreement will be terminated effective June 30, 2013. This is a direct result of the unconstitutional Minnesota state tax collection legislation passed by the state legislature and signed by Governor Dayton on May 23, 2013, with an effective date of July 1, 2013. As a result, we will no longer pay any advertising fees for customers referred to an Amazon Site after June 30 nor will we accept new applications for the Associates Program from Minnesota residents.

As near as I can tell, Amazon has neatly evaded the law, which added:

(b) A retailer is presumed to have a solicitor in this state if it enters into an agreement with a resident under which the resident, for a commission or other substantially similar consideration, directly or indirectly refers potential customers, whether by a link on an Internet Web site, or otherwise, to the seller.

So: Chuck out all the affiliates, collect no tax, done and done.  The state is no better off, and the bloggers in the state are worse off.  This is exactly what has happened in other states, so it should come as no surprise to our esteemed legislators.  I get it that states are hurting from dropping sales tax from brick and mortar stores and are looking for solutions, but it should have been obvious to anyone paying attention that this law would have very little effect when it’s this simple for places like Amazon to avoid it.

I was tempted to purge all links to Amazon from the blog – why send my good readers there for free?  ;)  But going forward, I guess I’ll try VigLink, which is sort of an affiliate of affiliates, and seems immune from this kind of thing, at least for now.  It looks trivial to switch over to w/o needing to go fix up any existing articles.  Hopefully it won’t make me look too craven; I’ll fine tune it as we go along.

1.5% doesn’t sound like a whole lot, but what does it really mean in terms of physical solar PV deployments?  Numbers have been tossed around that this will require 450MW of new capacity in the next 7 years.

Assuming the 450MW number is correct, and picking 250W panels as a common panel size today, that’s 450,000,000 / 250 = 1,800,000 or 1.8 million panels installed by 2020.  That’s about 700 panels installed every day for 7 years.

If commodity sized (65x39cm) panels are used, that’s about 112 acres of panels (if they were laid out flat and edge to edge, which of course they aren’t) ;)  That’s roughly equivalent to 112 US football fields.

Is this possible?  Sure.  Austria installed 230MW in 2012 alone.  New Jersey installed 415MW in 2012.  And Minnesota gave itself 7 years to accomplish this goal.

Is 450MW the right number?  According to the NREL PVWatts calculator for Minneapolis, 450MW of optimally situated, fixed solar PV could be expected to generate 578,512 MWh of solar energy in the course of a year.

According to the EIA energy data browser, all utilities (including co-ops etc) in Minnesota generated 42,586,000 MWh in 2012.  578,512MWh is about 1.3% of that number.  Xcel is by far the largest generator, so if we take out the smaller co-ops etc, 450MW does seem like a reasonable ballpark number.

There are already large companies ready to jump at this.  Geronimo Energy has submitted a proposal to provide up to 100MW of capacity at up to 31 sites ranging from 2 to 10MW.  I honestly hope this isn’t the predominant mode of development.  We have an awful lot of flat roofs which would be well suited – for example, Ikea put 1MW on their Minnesota store last year.  100 acres or so isn’t all that much land, but I’d still rather see this go up on the built environment before we start using farmland & green space.

I’m excited to see how this works going forward.  Will my friends in the small-scale solar installation business stay busy?  Will SolarCity come to town?  Will companies like Geronimo make up the bulk of this with giant installations?  Will it reduce the need for new gas peaker plants?  Time will tell, but it’s an exciting time for solar in Minnesota, for sure.

A photovoltaic inverter is a device which converts the DC energy from the panel into AC energy for the grid; it also manages optimum power point tracking.  Traditionally this was done with a big central inverter for all panels combined; recently companies such as Enphase Energy have started making microinverters, which are per-panel devices.  One advantage of these devices is that each panel operates independently so that if one panel is shaded, damaged, or dirty, it doesn’t affect the rest of the array.

I have 11 230W Solar PV panels on my roof with an Enphase M190 micronverter on each.  These are nominally 190W devices, though in practice they have a maximum output of 199W.  (Note, these are 3 year old models; Enphase now has microinverters with more capacity).  The fact that the panels can produce more than the microinverter can handle might seem like an issue; indeed on a cool, clear day we can see the effect:

So from the graph above it’s clear that I am losing a little energy production during that clipping.  What would normally be a smooth curve is flattened out at the top as I hit the 11x199W = 2189W limit.  (A few factors affect whether this clipping happens; obviously we need a clear day, but optimal sun angle and, perhaps more than anything, panel temperature affects it greatly).

I wanted to try to quantify this a bit – how much am I really losing from this behavior?

One cool thing about the Enphase units is that they report data every 5 minutes, and this data can be queried via a standard data API.  So I pulled down the past 365 days worth of data to see how often I was clipping.  I grabbed 5-minute data files for each day, and looked for when clipping seems to start, by looking at watt output around the clipping point, and how many 5-minute entries there were for each wattage:

$ egrep -w "21[789][0-9]" *.json | awk -F : '{print $8}' | sort | uniq -c
   9 2170,"enwh"
  10 2171,"enwh"
  15 2172,"enwh"
  11 2173,"enwh"
  17 2174,"enwh"
  17 2175,"enwh"
  11 2176,"enwh"
  20 2177,"enwh"
  24 2178,"enwh"
  14 2179,"enwh"
  17 2180,"enwh"
  21 2181,"enwh"
  32 2182,"enwh"
  51 2183,"enwh"
 107 2184,"enwh" <-- actual clipping start?
 166 2185,"enwh"
 134 2186,"enwh"
 119 2187,"enwh"
  97 2188,"enwh"
  62 2189,"enwh" <-- nominal clipping, 11x199
  21 2190,"enwh"
   2 2191,"enwh"

There’s a pretty big jump at 2184W, so I went with that as a definition of “when clipping starts” vs. the nominal 2189W.  Adding up the occurrences of clipping, I got 708 5-minute intervals of clipping out of the last 365 days.  That’s about 59 hours.

So how much energy is that?  My panels can nominally make 11x230W = 2530W of output, so 2530-2184 = 346W lost, at most, during clipping.  That’s actually too high; not every instance above is clipping, and not every interval would have been making the maximum output.  So we’ll take that as a high estimate.

346W x 59 hours is 20,414 watt-hours, or about 20kWh.  At around $0.10/kWh, that’s about $2.00 of lost value.  Over the same year period, my array made 3,356 kWh, so 20kWh lost is about 0.6% of that.  I would hope that the microinverters made up at least that much by virtue of keeping the array going over the winter when some panels were snow-covered, etc.  Remember, many of my assumptions above make this a high estimate.

One other interesting datapoint is to see when this clipping occured.  By month, here’s how it looks:

March was far and away the highest; this is probably due in large part to the cooler temperatures, which make the panels more efficient.

One counter-argument might be – well, you never know when anyone will turn on their AC, either, at least not minute-by-minute.  The grid is a balancing act; unpredictable, random loads have the same effect as unpredictable, random generators.

To which one might then counter yes, but there are so many AC units out there, they average out, more or less, turning on and off at random times and smoothing things out in aggregate.

To which the solar advocate might reply OK, then with enough solar the peaks and valleys of generation should cancel out too, as clouds move out of one area into another.  Does this seem likely out in practice?

To find out, I grabbed 5 minute data from about 40 Enphase systems in the twin cities on a highly variable, sporadically cloudy day.  Because we don’t yet have a whole lot of solar here, and I didn’t want the one or two large commercial systems in the group to swamp the smaller residential systems, first I normalized them all to a % of their max output.  (This might be cheating a little, but with a lot more systems randomly distributed in size and geography, the swamping-out effect should be minimiized.)  Here’s what just 4 of those systems looks like; each is indeed pretty messy and unpredictable at the 5-minute range:

Then I averaged all of the systems.  Here’s what the average looks like, compared to one of the individual systems:

It appears that things certainly do smooth out when we look at geographically distributed systems.  If I were a grid operator, I might feel a lot better about that.

The caveats might be that this is a very wide geographic range – I grabbed systems from all of the twin cities and suburbs.  And that’s probably larger than the various sub-grids within the cities; what the variability is within those subgrids is, or how this solar variability affects them, I’m not sure.  And of course my initial normalization of all systems to the same size could be argued with.

There have been much more rigorous papers and presentations written on this as well, see for example “Quantifying PV Power Output Variability” by Thomas E. Hoff and Richard Perez in 1999, and “Implications of Wide-Area Geographic Diversity for Short- Term Variability of Solar Power” by Andrew Mills and Ryan Wiser at LBNL in 2010.  But with the advent of 5-minute monitoring from systems like Enphase, I wonder if even better results could be found from this wealth of data.

[1]  I’ll submit that a sporadically cloudy day is more trouble to a grid operator than a generally cloudy day.   We often know if a day will be cloudy well ahead of time, and that doesn’t yield the minute-to-minute variations of a sporadically cloudy day.  The grid is better, I think, at responding to these longer-term variations.

The above changes are before Xcel proposed a slightly lower increase; it’s unclear how that will affect residential customers at this point, I guess.

Today marks the 1000th day of operation for the 2.53kw solar array on our roof.  Since we’ve installed it,

• 8.9 MWh of energy has been produced (almost 9kWh/day on average)
• 6 tons of CO2 have been avoided
• $1,100 in electricity costs have been avoided ($850 if I don’t count the optional fee for wind power I’ve subscribed to for years)
• 70% of our electrical consumption has been covered
• No maintenance has been required (other than optional snow removal)
• My inverter manufacturer (Enphase) has gone public
• My panel manufacturer (Siliken) has gone bankrupt.  (But warranties remain intact, in theory)
• Utility rebates from Xcel have dropped from $2.25/watt to $1.50 since we installed.

We’ve recently embarked on a plan to renovate the house, and may end up with a new flat roof on the back.  If so, I hope we can have space and budget to add another 1kW or so.

Minnesota has also continued to move forward on solar energy, with Ikea briefly holding the state record with a 1.1MW array on its roof, later eclipsed by a 2MW utility-scale system in Slayton, MN.  My utility, Xcel Energy wanted to eliminate the solar rebate altogether, but it was extended at a lower rate of $1.50/watt for now – appropriate, I feel, so that the solar industry has some planning runway, but rebates drop along with system costs.  There has also been some discussion of a 10% solar standard for Minnesota.  Solar Works in Minnesota!

(Image link goes to Amazon)

Read any collection of energy tips, and you’ll get pretty much the same thing.  Turn off lights behind you, unplug your cell phone charger, put your AV center on a power strip, etc.  The problem with these ideas, IMHO, is that you have to remember to do them, everyone in your family has to do them, and you have to keep doing them indefinitely to keep getting any benefit.  And face it, it’s hard to change behavior.

There are a few things I’ve found which make it simple and automatic to save energy, without adding too much hassle to daily routines, and without any significant expense or installation trickiness.

An example – My wife bought me a very nice espresso machine for my birthday about a year and a half ago; when it’s on, it’s using a lot of juice.  The group head has a resistive heater, and the boiler is keeping the water very hot.  I’d get up, make coffee, and then I’d be good for a while.  Almost invariably, I forgot to turn the machine off when I was done, and there it sat, drawing hundreds of watts, keeping itself warm for the next coffee I wasn’t going to make any time soon.  And worse, in the summer, it was adding heat to the kitchen.

Enter the device pictured above.  You press a button on the side, and it turns on and stays on for 30 mins, 3 hours, or 6 hours.  I set mine to the 30min setting, so when I make my coffee, I push the button, make the coffee, and walk away.  It turns itself off in 30 mins.  Done and done.  The beauty is, I have to take the action when I want something good to happen (like make coffee) – it’s a positive action, not “remember to do this when you are done.”

The other appliance I could use this device on is my stereo amplifier.  It pulls tens of watts even when not playing music.  Having the timed outlet set to 3 hours or even 6 would stop me from accidentally leaving it on over night.  A geekier and more satisfying solution, since my music source is a Logitech Squeezebox digital music player, would be to hook it to an X10-controlled switch, and tell the music server to turn on the amp whenever the device is active, and turn it off when it’s not.  I haven’t done either of those things yet, and sometimes the amp is on all night.

Of course, there are other “set it and forget it” ideas like setting computers to sleep when idle, installing motion-detector switches for lights (I prefer ones like this [amzn] which are manual-on, auto-off), programmable thermostats (if you actually program them), etc.  But I thought the device above was pretty slick for controlling random devices I’d rather not leave running when I’ve forgotten to turn them off.

Have you found any other unusual but simple, set-it-and-forget-it devices or ideas to help control unnecessary energy use?

The top line numbers:

• 2011: 839 therms, 4538 kWh consumed = 99.4 million BTUs
• 2012: 687 therms, 4577 kWh consumed = 84.2 million BTUs

On the face of it, that looks like quite an improvement, but the vast majority of the decrease was in natural gas, which is influenced by the weather.  We can use Heating Degree Days and Cooling Degree Days to quantify air conditioning requirements, and from degreedays.net, I find:

• 2011: 7357 heating and 1128 cooling degree days (@65F base)
• 2012: 6390 heating and 1238 cooling degree days (@65F base)

So we had about 13% fewer heating degree days, and consumed 18% fewer therms of natural gas, our primary heating fuel – fairly strong correlation, but maybe some improvement.  I don’t measure cooling energy independently (yet) so I can’t correlate that at all.

On the solar production side, we had this from our 11 panel, 2.53kW array:

• 2011: 3306 kWh, or 72.8% of our consumption
• 2011: 3352 kWh, or 73.2% of our consumption

Not a big change there.  So other than the weather, we didn’t have significant changes in our home other than slightly older kids, and the addition of a mini-split heat pump for AC & some heating.

I’ve mostly run out of ideas to make this old house more efficient.  Every light is CFL or LED, we’ve insulated the walls & attic, replaced the windows, etc.  We are considering some renovation, and that will probably change our energy use if we go through it.  I’ll keep you posted!

I iterated over the entire linux-2.6 git tree as of today (~3.7-rc8), and counted all commits (excluding merges), then counted up every Reviewed-by tag in all commits.  (I realize that this isn’t the only measure of review quality.  More caveats below).  It’s  possible that some commits might have more than one Reviewed-by tag, but I assume that’s rare overall.  I found:

4.7%: 313,848 commits, 14,631 reviews

Breaking it down further, for some of the top-level directories here’s what I found:

 0% sound: 12151 commits, 68 reviews
 1% virt: 451 commits, 8 reviews
 2% crypto: 888 commits, 23 reviews
 3% block: 1643 commits, 61 reviews
 4% security: 1675 commits, 68 reviews
 5% drivers: 149445 commits, 8107 reviews
 7% fs: 26747 commits, 2138 reviews
19% mm: 5858 commits, 1134 reviews

Changes Over Time

However, things seem to be improving.  Here is the total ratio of “Reviewed-by” tags to commits for each release since 2.6.13:

Perhaps Reviewed-by is coming into vogue; I find that interesting, since there has been no formal push for using Reviewed-by more often, as far as I know.  What if we look at those top-level subsystems only since v3.0?

 0% sound: 3341 commits, 32 reviews
 1% crypto: 185 commits, 2 reviews
 3% block: 303 commits, 10 reviews
 3% security: 406 commits, 15 reviews
 5% virt: 111 commits, 6 reviews
12% drivers: 40747 commits, 5054 reviews
15% fs: 5362 commits, 814 reviews
27% mm: 1193 commits, 325 reviews

mm/ continues to win, and improve the reviewed % as well.  fs, drivers, and virt have improved their percentage lately, too.

Filesystems

fs/ is second, and of particular interest to me.  How’s it doing since the beginning of the git tree?

1% fs/affs: 117 commits, 2 reviews
1% fs/bfs: 72 commits, 1 reviews
1% fs/coda: 143 commits, 2 reviews
1% fs/debugfs: 85 commits, 1 reviews
1% fs/fuse: 399 commits, 5 reviews
1% fs/gfs2: 1233 commits, 13 reviews
1% fs/logfs: 124 commits, 2 reviews
1% fs/minix: 91 commits, 1 reviews
1% fs/ncpfs: 121 commits, 2 reviews
1% fs/nfs: 2731 commits, 36 reviews
1% fs/ocfs2: 1578 commits, 29 reviews
1% fs/omfs: 57 commits, 1 reviews
1% fs/pstore: 64 commits, 1 reviews
1% fs/reiserfs: 512 commits, 7 reviews
1% fs/sysv: 95 commits, 1 reviews
2% fs/9p: 369 commits, 8 reviews
2% fs/autofs4: 216 commits, 6 reviews
2% fs/btrfs: 2607 commits, 55 reviews
2% fs/hostfs: 96 commits, 2 reviews
2% fs/hppfs: 46 commits, 1 reviews
2% fs/jbd: 172 commits, 4 reviews
2% fs/nfsd: 1358 commits, 33 reviews
3% fs/devpts: 57 commits, 2 reviews
3% fs/ecryptfs: 403 commits, 16 reviews
3% fs/ext2: 314 commits, 10 reviews
3% fs/ext3: 516 commits, 19 reviews
3% fs/jbd2: 222 commits, 8 reviews
3% fs/lockd: 376 commits, 14 reviews
3% fs/ubifs: 471 commits, 16 reviews
3% fs/udf: 306 commits, 11 reviews
4% fs/nls: 23 commits, 1 reviews
4% fs/quota: 116 commits, 5 reviews
4% fs/ramfs: 70 commits, 3 reviews
5% fs/ext4: 1629 commits, 93 reviews
6% fs/hugetlbfs: 131 commits, 9 reviews
6% fs/proc: 934 commits, 62 reviews
7% fs/ceph: 673 commits, 51 reviews
16% fs/cifs: 1741 commits, 286 reviews
50% fs/xfs: 2376 commits, 1204 reviews

Any fs not listed above had < 1% Reviewed-by tags.

I’m interested primarily in xfs, ext4, and btrfs for my day job.  How have they done over time?

(XFS exceeds 100% at times when many commits have more than one Reviewed-by tag.)

The Caveats

Now, granted: all this measures is the number of aforementioned Reviewed-by tags per commit in the tree; the absence of a tag does not necessarily mean there was no review. And, in many cases, it may be that the maintainer has done a review, and it’s unusual for the maintainer to add Signed-off-by as well as Reviewed-by.  And finally, presence of the tag does not say anything about the quality of review. So take this with as big a grain of salt as necessary. If you’re the maintainer of one of these subsystems, and Reviewed-by is not what you use, I’d like to know (and to know why that is). Meanwhile, this seems like the best measure we’ve got.

Finally, who are the top ten individuals with the most Reviewed-by: tags since the git tree’s inception?

213     Reviewed-by: Jesse Barnes <jbarnes@virtuousg---.org>
227     Reviewed-by: Chris Wilson <chris@chris-wil---.co.uk>
238     Reviewed-by: Josh Triplett <josh@joshtripl---.org>
245     Reviewed-by: Mike Christie <michaelc@cs.w---.edu>
255     Reviewed-by: Dave Chinner <dchinner@red---.com>
284     Reviewed-by: Michael Chan <mchan@broad---.com>
362     Reviewed-by: Pieter-Paul Giesberts <pieterpg@broad---.com>
435     Reviewed-by: Roland Vossen <rvossen@broad---.com>
478     Reviewed-by: Arend van Spriel <arend@broad---.com>
486     Reviewed-by: Christoph Hellwig <hch@---.de>

hch, somehow I am not surprised. :)

Edit: Everything else is bad!  Don’t get this device.  Really.  It’s the buggiest piece of junk I’ve had the misfortune of trying to run on my network.  I’ll leave the rest of this post here for posterity.

Unfortunately it doesn’t seem to do SNMP and there’s no way to monitor traffic.  On a whim I figured I’d look into the firmware and see if it offers any hints.  Just a note to the interwebs about how I got it unpacked:

First I ran binwalk to see what’s in it; that’s a cool tool I didn’t know about!

# binwalk-0.4.5/src/binwalk -m binwalk-0.4.5/src/magic.binwalk FW_X2000_AnnexA_2.0.04.007_20121009.bin

DECIMAL       HEX           DESCRIPTION
-------------------------------------------------------------------------------------------------------
256           0x100         Squashfs filesystem, little endian, non-standard signature,  version 4.0, size: 1746252031 bytes, 1243 inodes, blocksize: 0 bytes, created: Wed Jul  9 20:36:00 2025
352           0x160         LZMA compressed data, properties: 0x5D, dictionary size: 65536 bytes, uncompressed size: 65536 bytes
15110         0x3B06        LZMA compressed data, properties: 0x5D, dictionary size: 65536 bytes, uncompressed size: 13944 bytes
...

Ok, so maybe squashfs starting 256 bytes in.  So dd that out:

# dd if=FW_X2000_AnnexA_2.0.04.007_20121009.bin bs=256 skip=1 of=FW.squash

But squashfs tools won’t touch it.  What’s in it?

# hexdump -C FW.squash  | head -n 8
00000000  73 68 73 71 db 04 00 00  53 c6 73 50 00 00 01 00  |shsq....S.sP....|
00000010  78 00 00 00 01 00 10 00  c0 00 01 00 04 00 00 00  |x...............|
00000020  3f 1c f1 1d 00 00 00 00  19 6f 68 00 00 00 00 00  |?........oh.....|
00000030  11 6f 68 00 00 00 00 00  ff ff ff ff ff ff ff ff  |.oh.............|
00000040  b0 15 68 00 00 00 00 00  11 3a 68 00 00 00 00 00  |..h......:h.....|
00000050  2c 65 68 00 00 00 00 00  fb 6e 68 00 00 00 00 00  |,eh......nh.....|
00000060  5d 00 00 01 00 00 00 01  00 00 00 00 00 00 3f 91  |].............?.|
00000070  45 84 68 34 8a 09 0a 40  62 ae 9d db 78 c5 ce 30  |E.h4...@b...x..0|
...

Ok, that’s the “shsq” magic…

I tried the various unsquashers from the firmware mod kit but those failed too.  In the end, I grabbed the squashfs-4.2 tools from sourceforge and applied this patch:

diff -Nurp squashfs4.2/squashfs-tools/Makefile squashfs4.2-hack/squashfs-tools/Makefile
--- squashfs4.2/squashfs-tools/Makefile	2012-11-30 12:26:45.958576463 -0600
+++ squashfs4.2-hack/squashfs-tools/Makefile	2012-11-30 12:24:21.969566639 -0600
@@ -26,7 +26,7 @@ GZIP_SUPPORT = 1
 # To build using XZ Utils liblzma - install the library and uncomment
 # the XZ_SUPPORT line below.
 #
-#XZ_SUPPORT = 1
+XZ_SUPPORT = 1

 ############ Building LZO support ##############
diff -Nurp squashfs4.2/squashfs-tools/squashfs_fs.h squashfs4.2-hack/squashfs-tools/squashfs_fs.h
--- squashfs4.2/squashfs-tools/squashfs_fs.h	2011-02-11 09:49:24.000000000 -0600
+++ squashfs4.2-hack/squashfs-tools/squashfs_fs.h	2012-11-30 12:24:49.310566558 -0600
@@ -270,10 +270,10 @@ struct meta_index {
 typedef long long		squashfs_block;
 typedef long long		squashfs_inode;

-#define ZLIB_COMPRESSION	1
-#define LZMA_COMPRESSION	2
-#define LZO_COMPRESSION		3
-#define XZ_COMPRESSION		4
+#define LZMA_COMPRESSION	1
+#define XZ_COMPRESSION		2
+#define ZLIB_COMPRESSION	3
+#define LZO_COMPRESSION		4

 struct squashfs_super_block {
 	unsigned int		s_magic;
diff -Nurp squashfs4.2/squashfs-tools/unsquashfs.c squashfs4.2-hack/squashfs-tools/unsquashfs.c
--- squashfs4.2/squashfs-tools/unsquashfs.c	2011-02-28 16:27:06.000000000 -0600
+++ squashfs4.2-hack/squashfs-tools/unsquashfs.c	2012-11-30 12:28:31.793690803 -0600
@@ -1460,10 +1460,10 @@ int read_super(char *source)
 	 */
 	read_fs_bytes(fd, SQUASHFS_START, sizeof(struct squashfs_super_block),
 		&sBlk_4);
-	swap = sBlk_4.s_magic != SQUASHFS_MAGIC;
+	swap = 0;
 	SQUASHFS_INSWAP_SUPER_BLOCK(&sBlk_4);

-	if(sBlk_4.s_magic == SQUASHFS_MAGIC && sBlk_4.s_major == 4 &&
+	if(!swap && sBlk_4.s_major == 4 &&
 			sBlk_4.s_minor == 0) {
 		s_ops.squashfs_opendir = squashfs_opendir_4;
 		s_ops.read_fragment = read_fragment_4;

And after that hackityhack, it does unpack. And what do you know, it does have busybox:

# ls -l bin | grep busybox
-rwxr-xr-x. 1 root root 323640 Oct  9 01:38 busybox
lrwxrwxrwx. 1 root root      7 Nov 30 12:25 cat -> busybox
lrwxrwxrwx. 1 root root      7 Nov 30 12:25 chmod -> busybox
lrwxrwxrwx. 1 root root      7 Nov 30 12:25 cp -> busybox
lrwxrwxrwx. 1 root root      7 Nov 30 12:25 date -> busybox
lrwxrwxrwx. 1 root root      7 Nov 30 12:25 dd -> busybox
...

And apparently runs the Linux kernel:

# ls lib/modules/
2.6.30

So, ok, Cisco/Linksys, where’s the GPL notifications etc?  I haven’t seen anything obvious, but their GPL download center doesn’t seem to have anything for this box.  Is it a GPL violation?  I sent a request through their normal process, we’ll see what happens.  :(

Sadly, no hints about SNMP in there, either.

Edit:  Although the “GPL code center” has no download for this box, I did obtain source via a request, and apparently there is a source offer buried deep on the setup CD.  I’ll see if the source builds, next, I guess.