rwg

I want to like this — I think having ground-based alternatives to GPS and other space-based PNT systems is a very good thing! But after reading the paper at https://www.nab.org/bps/Broadcast_Positioning_System_Using_A... and other BPS information on the NAB's website, I think the NAB is being wildly optimistic about BPS:

• ATSC 3.0's physical layer can already transmit GPS time in a way that receivers could get it back out. What BPS brings to the table is a requirement and specification for accurately and consistently filling in the physical layer preamble fields containing the time data, along with a new physical layer pipe (think "low-level data stream") that contains additional information about the transmitter and, optionally, its neighboring transmitters.

• BPS is capable of producing time fixes when the receiver only has a lock on one source. This isn't surprising at all — GPS receivers can do the same thing. But either type of receiver with only one source would see a clock offset proportional to the path delay, which it wouldn't be able to compute and back out without knowing its position.

• BPS is only designed for 2-D position fixes. While that's a reasonable design decision (the vertical position error would be massive), it also makes BPS less useful for the NAB's "indoor positioning for first responders" use case, especially in areas with multi-story buildings.

• The need to receive and process/decode multiple, most likely non-adjacent 6 MHz channels for positioning increases receiver complexity and cost.

• The NAB claims that 1 kilometer of separation between two BPS transmitters is "sufficient for useful position determination." I don't buy it, especially in the face of poor transmitter geometry.

• They note that 16 TV stations in the New York City area broadcast from One World Trade Center, so for the purposes of BPS, they're effectively one station. This kind of transmitter colocation is incredibly common, both in urban areas (ten TV stations broadcast from Sutro Tower in San Francisco) and in more rural areas (six TV stations in the Roanoke-Lynchburg DMA broadcast from towers within ~1 mile of each other on the ridgeline of Poor Mountain). Even if every ATSC TV station became an ATSC 3.0 w/ BPS transmitter, bad transmitter geometries would destroy BPS's position accuracy in lots of markets.

• What's the business case for broadcasters? BPS won't be free for broadcasters to implement, and there doesn't seem to be a path to it generating revenue except for a hand-wavy "maybe one day televisions will be able to determine their locations without Internet connections using BPS, and then broadcasters can do location-targeted advertising with those TVs!"

My uncharitable take is that BPS will never be a usable standalone PNT system. A timing system in the "rebroadcasts GPS" sense? Maybe. Standalone positioning? No way. Broadcasters implementing BPS (or ATSC 3.0 at all) without being forced to by the government? I don't see it.

I was merely a Kickstarter backer of CastAR and have no insider knowledge, but my guess is that a failed moonshot attempt happened here.

After raising $1 million on Kickstarter, Technical Illusions/CastAR received an investment from Andy Rubin's Playground Global. CastAR later announced that they would refund Kickstarter backers' money and give everyone who backed at a level that would give them a pair of CastAR glasses a voucher for the retail CastAR glasses, whenever they released. Somewhere along the way, CastAR also changed course from "AR glasses tethered to a computer/phone" to "standalone AR glasses." Then they acquired Eat Sleep Play, a game studio in Salt Lake City. Then they went bankrupt.

Instead of releasing a product (even a rough, beta-quality product!) for their Kickstarter backers and iterating from there to a retail-quality product, it seems they took their VC money and went straight for a moonshot standalone product with first-party games available out of the gate. The moonshot was expensive, Playground Global declined to invest further, and here we are.

I have an HP MicroServer N40L that I bought several years ago, and it's almost a doorstop now. Its CPU (dual-core 1.5 GHz AMD Turion II Neo) is slow and doesn't support AES-NI. It maxes out at 8 GB of RAM (16 GB of RAM if the stars align and it likes the RAM you bought). It has one GigE port, and SATA ports are limited to 3 Gbps (SATA II). Expansion is limited to an eSATA port, USB 2.0 ports, a low-profile PCIe 2.0 x1 slot, and a low-profile PCIe 2.0 x16 slot.

It's okay as a NAS that mostly sits idle and occasionally serves up unencrypted data at GigE speeds or less. For more demanding tasks, it's woefully underpowered.

At ${PREVIOUS_JOB}, I changed offices and discovered my window wasn't the only thing I lost in the move: SSH sessions kept dying with MAC errors. It happened with multiple computers with different NICs and running different OSes, so it wasn't computer-related. I tried swapping the patch cable, but that didn't change anything.

On a whim, I took the faceplate off the box containing my (100 Mbps) Ethernet and phone jacks and discovered both drops were provided over a single four pair cable originally installed in the late 1980s. More alarmingly, the outer jacket of the cable had been cut off about a foot from the punchdowns on the backs of the keystone jacks, and the entire foot of conductors emerging from the jacket were all untwisted and balled up in the box.

Cutting off about 10 inches of each wire, twisting the pairs back together, and punching the wires back down onto the backs of the jacks fixed the SSH problem...

Just to put a number to "screaming fast", 2.5 GB/s sequential reads averaged across the entire drive on a Samsung 950 Pro NVMe SSD: https://pbs.twimg.com/media/CaMhc2oVAAE4q3q.jpg:large

By comparison, today's (January 1996) state-of-the art technologies have feature sizes of about 0.25 microns.

And today (November 2015), chips manufactured on 14 nanometer (0.014 micron) processes are shipping in volume.

Android 4+ supports IPv6 on both the cellular and wireless Ethernet interfaces. It only supports stateless address auto-configuration (SLAAC), however, and does not support DHCPv6 at all. (There's a 3+ year old Android DHCPv6 bug that was declined/closed late last year for, IMHO, unconvincing reasons.)

The ~5 years between AMD's release of the Athlon 64 and Intel's Nehalem were truly AMD's glory days on the server. We had two clusters, one with pairs of 2.2 GHz Opteron 248 CPUs in its compute nodes and another with pairs of 3.4 GHz "Nocona" Xeons in its compute nodes. The Opteron nodes completely wiped the floor with the Xeon nodes in everything we threw at them, despite the Xeons enjoying a >50% clock speed advantage and a newer manufacturing process (90 nm vs. 130 nm).

Intel's "Core 2" CPUs scrapped the Pentium 4's NetBurst architecture in favor of an evolution of the Pentium M architecture (which was, in turn, an evolution of the Pentium III architecture), and Intel was competitive with AMD on the desktop again. Nehalem brought on-die memory controllers and QPI (Intel's HyperTransport-alike) in late 2008, which made Intel the performance champion on multi-socket servers. AMD's Bulldozer architecture was dead on arrival in 2011, and AMD never recovered from that.

Maybe AMD will pull a rabbit out of their hat with Zen...

There was no need, really. The university's networking/telecommunications group ran their own pair of stratum-1 NTP servers, plus four stratum-2 NTP servers, so my stratum-1 wasn't really needed. I ran my stratum-1 NTP server simply because the hardware was available and I had an interest in it. You see, the GPS clock (and its predecessors, a WWVB clock and a pair of GOES clocks) were relics of a time long past...

[insert wavy flashback transition here]

The lab I mentioned was a seismological observatory. In the days before cheap, high-resolution A/D converters and computers with massive amounts of storage existed, almost everything was analog. Gloriously, unashamedly analog.

Seismograph stations sent data from their seismometers back to the lab over a "dry loop" — a leased line with no dial tone or voltage on it — from AT&T. To do this, the seismometer's output signal was greatly amplified, then frequency modulated onto a relatively low frequency carrier (1–2 kHz). The signal then traveled through AT&T's network all the way to the lab, where the signal was demodulated.

Okay, great, we're getting the signals back at the lab, but how do we store these waveforms? The answer is a giant drum, a motor, some paper, and a pen or stylus — a drum recorder.

http://www.aeic.alaska.edu/input/west/proj/ASRA/2007/picture...

"Helicorder" was Teledyne Geotech's brand name for their line of drum recorders, but it was so popular that "helicorder" has become a generic name for "drum recorder" in the seismological community, much like "Xerox" became synonymous with "photocopier." (If you ever look at earthquake records on-line, check for "heli" in the URL.)

A piece of paper is wrapped around the drum. A pen/stylus rests on the paper and deflects side-to-side depending on the polarity and magnitude of the input signal. A big positive voltage makes the pen move really far to one side, and a small negative voltage makes the pen move not so far to the other side. The pen is also attached to a threaded shaft that rotates, slowly moving the pen from one side of the paper to the other. The drum itself also rotates, and the rotation speed of the drum and the shaft was usually selectable — most people had recorders with small drums set to record ~24 hours of data per piece of paper, with wider drums set to record for a proportionately longer amount of time. (The higher the drum speed, the better the record quality, but then you had to change the paper more often.)

So we can record the signal onto paper, but we're missing a very important thing — time. We need to know exactly when stations saw ground motion in order to locate earthquakes and other seismic events. Enter the GPS clock (and the WWVB clock and GOES clocks before it). The GPS clock received a very accurate time signal and was configured to output a very simple timecode known as "slow code." Slow code works as such:

• At exactly the start of the 0'th second of every minute, generate a voltage pulse for some amount of time, usually 2 seconds.

• At exactly the start of the 0'th second of the 0'th minute of every hour, generate a voltage pulse for some longer amount of time, usually 4 seconds.

• At exactly the start of the 0'th second of the 0'th minute of the 0'th hour of every day, generate a voltage pulse for some even longer amount of time, usually 6 seconds.

This slow code would be added to the signal being recorded by the drum recorder, adding precisely timed "bumps" to the record. When the paper was changed on the drum every 24 hours, someone would write or stamp several pieces of information on the paper: the seismograph station's name, the date, and the time of the first time mark:

http://www.hilo.hawaii.edu/~nat_haz/earthquakes/media/SeisDE...

Note the column of time marks between the stamped dates. The narrow marks are minute marks, the slightly wider marks are hour marks, and the widest mark (five lines above the little earthquake) is the day mark.

[insert wavy flash-forward transition here]

Eventually, everything at the seismological observatory went digital, and the seismograph stations were upgraded with digitizers that had their own GPS clocks for timestamping data. The WWVB clock and GPS clock sat unused until I cleaned them up and reconfigured them to serve up time for ntpd to consume.

At ${PREVIOUS_JOB}, I ran a stratum-1 NTP server that got a timecode and PPS signal from a GPS clock. I could tell if someone had left the door to the lab open by what PLL frequency "ntpdc -c kerninfo" reported on that server — the various oscillators in the server would drift above/below their ideal frequencies depending on how hot/cold they were, and the room would get a few degrees colder with the door open.

I don't know if they inject ads, but they have the capability to do it. When I connect to an "xfinitywifi" SSID, the first HTTP page load I do will have a little "You're using XFINITY Wi-Fi. Isn't it totally awesomesauce?!"-style pop-up appear for a few seconds in the lower right corner of the browser window.

I'm guessing it's related to IPv6 over Bluetooth Low Energy, which is currently working its way through the bowels of the IETF:

https://tools.ietf.org/html/draft-ietf-6lo-btle

Basically, they saw what a glorious success 6LoWPAN (IPv6 over 802.15.4) has been (</sarcasm>), realized BLE/L2CAP has a fair bit in common with 802.15.4 (focus on minimizing power consumption, low data rates, crazy small per-packet payload sizes), and decided to reuse 6LoWPAN's IPv6 header compression (RFC 6282) in this IPv6-over-BLE standard.

Woo, nostalgia! My father's TRS-80 Model 4P was "my" first computer back in the mid- to late-1980s, and I spent more time on it than an elementary school kid probably should've. (Every time a new issue of Family Computing showed up in our mailbox, I'd grab it and flip through it to see if whatever games were in that issue had TRS-80 Model III or 4 versions...)

The "P" in "Model 4P" stood for "portable" — it was a modified Model 4 that was shrunk down to something roughly the size of a sewing machine. It had a handle on the back. Tandy's advertisements proudly proclaimed that it fit in overhead bins on airplanes. I feel sorry for anyone who actually tried that.

As far as specs, the 4P had a 4 MHz Z-80, a minimum of 64 kB of RAM, one or two single-sided double-density (SSDD) 5.25" floppy drives, and an 80x24 text mode. There was an optional 640x200 monochrome graphics card, but it doesn't look like this demo is using that. (I'd bet it's using the graphics characters in the Model 4's 80x24 text mode — faster and less data to deal with.) If I'm remembering correctly, the SSDD disks held ~180 kB, so there's less than half a megabyte of data in play for this demo. I'm kind of amazed at the sound in this demo — I'd never heard the speaker in my 4P ever make any noises other than simple beeps.

Semi-related trivia: The "best" word processor for the Model 4, SuperSCRIPSIT, was laid out on its program disk in such a way that the drive head's stepper motor played something that almost sounded like a song when it was loading itself off of the disk. Even ~30 years later, I can still hear SuperSCRIPSIT's loading sound in my head...

You need to talk to a lawyer who specializes in Texas employment law ASAP. Do not sign anything that you do not fully understand the implications of, even if your reading of the non-compete agreement and Texas's Covenants Not to Compete Act makes you think the agreement is completely unenforceable.

While you're talking to the lawyer, don't forget to ask if the non-compete agreement is still in effect in the event you're "involuntarily separated" (sacked, with or without cause) from the company. The answer may greatly influence your decision.

Finally, as is mentioned elsewhere in the comments here, do not sign anything because random HR person says whatever you're signing is never really enforced. HR does not work for you, and "but so-and-so in HR said..." is not a strong defense against your signature on a contract. If the non-compete is never enforced, then the company should have no problem with you not signing it.

Solaris 9+, recentish Linux, and recentish BSD should all support algorithm $1$ (MD5) at an absolute minimum. Depending on OS versions, you might also be able to choose from $2a$ (Blowfish), $5$ (SHA-256), and $6$ (SHA-512). On Solaris, the list of supported algorithms is in /etc/security/crypt.conf. "man 3 crypt" might tell you what's supported on your Linux and BSD machines.

For NIS, you'd need to ensure that every machine that touches passwords via NIS is configured to use the same algorithm when users change passwords. On Solaris, just configure CRYPT_* in /etc/security/policy.conf the same on every machine. (See the policy.conf man page — in short, you want to change the default algorithm to 1 [or whatever] and set __unix__ to be deprecated.) On Linux and *BSD, how you do it depends on the distro/version.

Fun fact about changing passwords in NIS: When a yppasswd client contacts rpc.yppasswdd to change a user's password, the user's new password is sent crypt()ed, but the user's old password is sent in the clear.

Why impossible? (Hint: 127/8 is a network, too.)

Another fun Unicode-related bug in OS X 10.9:

    % printf 'Unicode strike\xcd\x9bs again' | LANG=en_US.UTF-8 od -tc
    Assertion failed: (width > 0), function conv_c, file /SourceCache/shell_cmds/shell_cmds-175/hexdump/conv.c, line 137.
    0000000    U   n   i   c   o   d   e       s   t   r   i   k   e 
    zsh: done       printf 'Unicode strike\xcd\x9bs again' | 
    zsh: abort      LANG=en_US.UTF-8 od -tc

I think you're underestimating the number of poorly configured/written SMTP clients and servers out there in the wild. As an example, here's smtp.comcast.net on tcp/587 (SMTP submission):

    Connection to smtp.comcast.net port 587 [tcp/submission] succeeded!
    220 resomta-ch2-12v.sys.comcast.net comcast ESMTP server ready
    EHLO [2601:b:x:x:x:x:x:x]
    250-resomta-ch2-12v.sys.comcast.net hello [2601:b:x:x:x:x:x:x], pleased to meet you
    250-HELP
    250-AUTH LOGIN PLAIN
    250-SIZE 36700160
    250-ENHANCEDSTATUSCODES
    250-8BITMIME
    250-STARTTLS
    250 OK
    AUTH LOGIN
    334 VXNlcm5hbWU6

At least with tcp/465 (SMTPS), the SMTP session (and the potential to send plaintext credentials) won't even start until the TLS session is up. That limits the attack surface to, "Does the client do something stupid with TLS, like not verify the peer's certificate or accept an aNULL/eNULL ciphersuite?"

If the MUA has a "Use SSL?" checkbox in its SMTP settings and it's not checked, then the MUA will send its credentials in the clear on tcp/587 if the server advertises/accepts AUTH LOGIN/PLAIN/CRAM-MD5/etc. before/without SMARTTLS, like Comcast's SMTP servers do. This scenario can't happen with SMTPS.

This article came across my Twitter feed this morning:

MEEGO-T01 HDMI TV Stick Supports Android, Windows 8.1, and Ubuntu/Linux http://www.cnx-software.com/2014/10/15/meego-t01-hdmi-tv-sti...

There are other models by other OEMs out there, but I can't find any URLs for them off-hand.

Intel is almost giving away Bay Trail-T CPUs to try and claw marketshare away from ARM-based CPUs/SoCs. As an example, Intel's advertised price for an Atom Z3735F (quad core, 1.33–1.83 GHz, 2.2 W SDP, 2 GB RAM max., Intel's Gen7 graphics) is $17, but I've read that the "real life" price dips under $10 in volume. This is an absolutely mind-boggling price for a quad-core x86-64 CPU with really quite good integrated graphics.

An exciting (to me, at least) development is that OEMs are starting to produce sub-$100 HDMI sticks with Bay Trail-T CPUs and 16 GB–32 GB of eMMC storage inside. Assuming the firmware isn't crippled, those sticks should be able to run unmodified copies of any modern x86 operating system. On Linux and FreeBSD, there is stable, functional, non-proprietary GPU support, which is a huge win over the vast majority of ARM-based systems. (Even the "OPEN hardware and software platform" Matchstick is currently chained to a binary blob because of the Mali GPU. Maybe one day the reverse engineered Mali driver will be awesome, but it's not there yet.)

Also, "don't hack random companies and brag about it to your friends and (Federal government IT security contractor) co-workers."

http://www.archives.gov/research/military/ww2/photos/images/...

It's partially broken in Safari 7.0.6 for the same reason — the ellipse method isn't a WebKit-ism, it's a WHATWG-ism that Google's implemented: http://www.whatwg.org/specs/web-apps/current-work/multipage/...

A quick workaround is to run the following in the error console:

    ctx.ellipse = function (x, y, radiusX, radiusY, rotation, startAngle, endAngle, anticlockwise) { ctx.arc(x, y, Math.max(radiusX, radiusY), rotation, startAngle, endAngle, anticlockwise); }

Disassembling data structures nicely can take much more time than just tearing them down brutally when the process exits.

A wonderful trend I've noticed in Free/Open Source software lately is proudly claiming that a program is "Valgrind clean." It's a decent indication that the program won't doing anything silly with memory during normal use, like leak it. (There's also a notable upswing in the number of projects using static analyzers on their code and fixing legitimate problems that turn up, which is great, too!)

While you can certainly just let the OS reclaim all of your process's allocated memory at exit time, you're technically (though intentionally) leaking memory. When it becomes too hard to separate the intentional leaks from the unintentional leaks, I'd wager most programmers will just stop looking at the Valgrind reports. (I suppose you could wrap free() calls in "#ifdef DEBUG ... #endif" blocks and only run Valgrind on debug builds, but that seems ugly.)

A more elegant solution is to use an arena/region/zone allocator and place potentially large data structures (like cp's hard link/inode table) entirely in their own arenas. When the time comes to destroy one of these data structures, you can destroy its arena with a single function call instead of walking the data structure and free()ing it piece by piece.

Unfortunately, like a lot of useful plumbing, there isn't a standard API for arena allocators, so actually doing this in a cross-platform way is painful:

• Windows lets you create multiple heaps and allocate/free memory in them (HeapCreate(), HeapDestroy(), HeapAlloc(), HeapFree(), etc.).

• OS X and iOS come with a zone allocator (malloc_create_zone(), malloc_destroy_zone(), malloc_zone_malloc(), malloc_zone_free(), etc.).

• glibc doesn't have a user-facing way to create/destroy arenas (though it uses arenas internally), so you're stuck using a third-party allocator on Linux to get arena support.

• IRIX used to come with an arena allocator (acreate(), adelete(), amalloc(), afree(), etc.), so if you're still developing on an SGI Octane because you can't get enough of that sexy terminal font, you're good to go.

That's not a behavior you can count on — clang 3.4 will optimize doSecure() down to "ret" and main() down to "xorl %eax, %eax" + "ret" in both cases, for example. Also, gcc not optimizing out the malloc + memset in the heap case seems like a missed optimization that the gcc devs might fix in the future.

Section 4 ("Radios, we have Radios") really dates this article.

DARPA purchased four of the Spectracom WWVB receivers [...] The radios were redeployed in 1986 in the NSF Phase I backbone network, which used Fuzzball routers [26]. It is a tribute to the manufacturer that all four radios are serviceable today

Those receivers almost certainly aren't in use anymore.

There's a real problem with WWVB reception here on the east coast of the United States, especially in urban areas. NIST investigated several possibilities for improving reception, including building a second WWVB-like transmitter site in Alabama. (That plan ended up dying because of a dispute with NASA that never got resolved before the funding expired.) So they went with Plan B, a public-private partnership with a company named Xtendwave, where Xtendwave worked with NIST to design a phase modulated signal format for WWVB, NIST implemented the new phase modulated signal, and Xtendwave filed for and received patents on it all.

So NIST is currently broadcasting two signals on WWVB's carrier: the old amplitude modulated signal, which is prone to interference, and a new phase modulated signal that's more resistant to interference and has error-correction built-in. Unfortunately, when the phase modulated signal appeared, all of the "laboratory grade" carrier tracking WWVB receivers in the world (like Dave Mills' Spectracom receivers and a Kinemetrics/TrueTime receiver I had at ${PREVIOUS_JOB}) became instantly obsolete — they can't lock onto a carrier that's constantly, unexpectedly going 180° out of phase.

It's worth noting that Xtendwave has been saying that their line of receiver chips for the new phase modulated WWVB signal will be available Real Soon Now™ since at least late 2012, but you still can't buy them. Also, no one seems to know if you can build your own receiver for WWVB's phase modulated signal without running afoul of Xtendwave's patents.

So, yeah, NIST obsoleted working equipment actively used in industry in order to provide a "better" time signal that nobody can actually make use of. Yay.

These four radios, together with a Heath WWV receiver at COMSAT Laboratories and a pair of TrueTime GOES satellite receivers at Ford Motor Headquarters and later at Digital Western Research Laboratories

GOES is NOAA's geostationary weather satellite program, and NOAA used to broadcast a publicly documented timecode from those satellites. NOAA finally killed the time service a decade ago because GPS existed, there was almost no funding to keep the GOES timecode going, and the ground hardware used to drive the service was obsolete.

There's a nice GOES retrospective at http://tf.nist.gov/general/pdf/2013.pdf

How cheap is dirt cheap? $1000? $100? $10? $1? $0.1?

I think a sub-$500 per-station cost would be wonderful, but this is all just a pipe dream...

Are there established algorithms to determine what seismic data is 'interesting' as opposed to streaming it all in real time (and keeping the radio on) constantly?

Almost all digitizers I've seen support the same STA/LTA (short term average ÷ long term average) triggering mechanism, where data is declared interesting if the energy over a short time window divided by the energy over a long time window exceeds some configurable threshold. If you only send triggered data, it's a great way to trigger repeatedly on local noise and miss all/parts of events you actually want to record.

Sending continuous data from stations to a central processing site is greatly preferred, especially since the data rate is so low. Three channels of 20-bit, 100 samples/s data from a low- to moderate-noise site that's losslessly compressed by the digitizer fits comfortably in 9600 bits/s.

Why 802.11n instead of cell phone networks - don't you need to be away from traffic vibrations, and hence roads and homes?

Siting seismograph stations is a tradeoff. Too far away from civilization and you have no way to get data back home except via (expensive, power hungry) VSAT or high power radios. Too close to civilization and you are subjected to civilization's noise (but you can use civilization's communications infrastructure to send your data home, sometimes for free).

The higher a site's noise level, the higher your event detection threshold gets. In other words, the noise consumes the signal from weak and/or distant earthquakes. You can make up for this somewhat by deploying a more dense network that pushes stations closer to where the earthquakes are happening...

As someone who used to work for a university's geosciences department as a Unix sysadmin/programmer and who worked on two different seismic monitoring networks (one spread across the state for earthquake monitoring and one parked on top of a coal mine), allow me to explain why earthquake monitoring in the United States is largely stuck in the stone age: There's no f---ing money.

Back in the '80s, there were a lot of regional seismic networks around the country, especially east of the Mississippi. But as time marched on and budgets got slashed, regional seismic networks disappeared one by one. Today, only the largest regional networks survive — generally the ones that are mostly funded by the states they're in and/or have increased their share of USGS/ANSS funding by taking over monitoring for areas of the country that used to be covered by the now-defunct networks.

The regional seismic networks that are left spend pretty much all of their dollars on equipment and operations. Installing/upgrading/running permanent seismograph stations is expensive — a basic solar-powered one with a shallow fiberglass vault, a three component short period sensor, and a three channel digitizer will run you ~$12,000 just in equipment and materials. The sky's the limit if you go fancier than that (broadband sensors, strong motion sensors, atmospheric sensors, borehole sensors, six channel digitizer, elaborate vaults, VSAT, etc.). Then there's the recurring communications cost, the cost of regular site visits, the cost of regular battery replacements, replacing solar panels/equipment boxes that morons shoot at for laughs, etc.

What I'm getting at is that in the monetary battles of "keep seismograph stations working" vs. "hire programmer to write useful software", the stations will win every time. Even this LA Times article about Berkeley's early warning system notes, "A lack of funds, however, has slowed the system's progress."

If the epicenter of tech wants to do something wonderful for earthquake seismology, figure out how to make dirt cheap 1- or 3-channel seismic digitizers (low-pass filter + low noise amp + 20-bit ADC @ 100–200 accurately timestamped samples/s, ≤1 watt average power draw @ 12 VDC, speaks TCP/IP over 802.11g/n) and dirt cheap 1- or 3-component short period sensors (1 or 2 Hz corner frequency, decent sensitivity). Then figure out how to get thousands of these dirt cheap digitizers and sensors in backyards all over the country and contributing data in real-time to IRIS and/or the closest regional seismic network. If the cost of acquiring quality seismic data goes down, that frees up money to actually do something with the data.

When I was still at the university job, my job-related pipe dream was to blanket the state with these non-existent dirt cheap stations. Even one or two per county in my state would've increased our station count by a factor of >15, greatly improved the quality of our earthquake locations, and allowed us to determine focal mechanisms (the orientation of the fault and direction of the slip) even for small earthquakes.

It even successfully un-mangles the shipping label from Ode to a Shipping Label: https://www.facebook.com/cmb/posts/619241744770551:0

    >>> ftfy.fix_text('López')
    'López'

The default partitioning of CAM space on Cisco gear is the obvious issue, but the root cause is the massive deaggregation of announced IPv4 routes on the Internet. You can see various statistics about this problem at http://www.cidr-report.org/, but the short of it is that if the top 30 networks (based on announced route savings) completely aggregated their announcements as much as possible, ~41,000 routes (~8% of the routing table) would be eliminated.

And that's just the top 30 networks — if every network cleaned up their announcements, it would eliminate ~232,000 routes (~45% of the table).

Adding to the deaggregation problem is the inability to easily filter out route announcements based on RIR minimum allocations without having to add tons of exceptions for CDNs that operate as islands of connectivity and carve out IP space for each island from a single address space allocation. (There's no covering route for the islands of connectivity since these CDNs have no "backbone" connecting the islands, so if you filter out those smaller announcements, you lose connectivity to those islands.)

There are many people who think this problem will just magically go away as IPv6 adoption increases, but all increased IPv6 adoption will do is make limited CAM space even more limited as network engineers have to balance dividing precious CAM space between a ballooning-quickly IPv4 route table and a ballooning-slightly-less-quickly IPv6 route table.

(To be clear: I think ubiquitous, functioning, end-to-end native IPv6 connectivity needs to happen sooner than later, but it's not a magic bullet for the Internet's technical problems.)

Be warned that Linode's status page is also borderline useless. Their website and web-based management interface (and API, according to customers on their IRC channel) were throwing 500 Internal Server Errors for >2 hours the other night, and their status page never had any mention of it.