IPAWS has a (just barely out of development AFAIK) private RSS feed that you need a special pin code or something for. It is just for broadcasters. They also have a private SOAP server that you need some X509 certs for to pull public CAPs from (this is a superset of EAS alerts).

IPAWS eventually will have a public RSS feed for EAS messages, but they don't seem as concerned about making sure that it will be properly provisioned to serve millions of clients hitting it up constantly.

I'm developing an OSS application to feed IPAWS messages from their SOAP server to a public xmpp server: https://github.com/talisein/Stormee

Its not really ready for prime time yet, but I should have something that works in a couple weeks.

If anybody's interested, I'm developing a GTK+ app that gets alerts from IPAWS pushed to it. Its not quite ready to be useful yet (I need to get certified to pull from the IPAWS production server rather than just their dev server), but I'm getting there; I expect I'll have a usable beta out in a month.

https://github.com/talisein/Stormee

Feedback is welcome

No, Google can do this because THEY OWN THE CODE in question. They developed Android, not random FOSS people.

The thing they are using from the wider community is the linux kernel (and some tools like gcc), AND THEY HAVE RELEASED THAT CODE. The whole rest of the Android stack was developed in house at Google and they can do whatever the fuck they want with it, be it release the source or not on their own time table.

I haven't done the math, but at 500 GHz it seems like dispersion would make any network longer than a single chip fundamentally unable to use that kind of frequency.

For a mesh network-on-a-chip though, you could probably dumb down the routers a lot (you'd have to to let them operate at that freq), and basically trade inefficient routing for a way higher link rate... basically operate the network such that you can deliver a message 100 times faster than than you can send 1 message. The routers may not even need buffers at that point. But I think there are a lot of problems here.

I think the parent comment is right: 500 GHz modulator is nice and all, but its difficult to use until everything else is at least on the same order of magnitude.

I don't think you understand that Android isn't developed in the bazaar. While they do accept community improvements, it takes a LONG time for the patches to be approved--up to a year even for relatively small changes; and as of TODAY the community itself is completely unorganized--absolutely unable to address this kind of focused rewrite in anyone's idea of a reasonable timeframe.

Maybe Android would be better off in the bazaar, but I think they think they are doing quite well enough with their current development model, and it is their choice!

Having the source code to modify it IS great and IS the reason to have it.

But if the Honeycomb source is as fucked up as they say it is, and as fucked up as the comments in this post have said it is, then your modifications would certainly break almost beyond repair in their massive refactoring for the next version.

If your work depends on the source to Honeycomb and you don't have it because you're a small fry, well, that sucks, sure. OTOH if they hadn't done it this way then there wouldn't be a Honeycomb, there wouldn't be an Android tablet yet, and you would still be sitting on your ass left waiting for a release.

Honeycomb is less of a release than it is a closed beta, that's all. Hell, at least this way we at least know what some of the APIs are before the real release, right?

Unless your intent and purpose is that you just want to be able to see and use what people do to your source code and not dictate how people build their hardware.

Ultimately these companies rise and fall by the geeks that work for them; if Google does shed its skin and shows some evil nature of closed development or something.... then things will be inconvenient for a few years, they'll bleed the developers who understand the importance of openness (which seems to be a pretty large proportion of Android's devs), and eventually they'll be as irrelevant as Microsoft.

Before he said any of that, he said you have to understand the nature of git: When they release Ice Cream Sandwich, the Honeycomb source will be in the patch history. What they may not bother to do is to tag the specific commit of Honeycomb.

But once Ice Cream Sandwich is released, I have no idea who the fuck would care about Honeycomb; the only reason would be for a device that had proprietary drivers that never updates to Ice Cream Sandwich, but that could be solved pretty easily by just pinning the kernel release to Honeycomb and taking the rest of ice cream.

All this hand-wringing over Honeycomb is fucking annoying at this point. Get over it.

Science does NOT say how things "really are." Science provides a model that provides an approximation of reality; the most complex models can predict real events with a high statistical accuracy, but the the universe (or God if you want) is the only thing that knows what is really going to happen. If you don't know what an "atom" is, then you simply do not have a model from which to predict molecular events. When you read in a book about "atoms" you are just memorizing a model, giving you a framework that allows you to make some predictions. There is no requirement of faith in the model. If you make a prediction from the model that fails to realize, then you need to use a different model! That's all. Science is explicitly not a guarantee, but our modern models give very accurate predictions in many situations.

Faith on the other hand IS a statement of how things "really are". Faith is explicitly a guarantee and allows for zero prediction this side of death. And that's fine.

When a scientist tells you what a boson is, you DO NOT need to "trust" or "believe" them. The world's best scientists are in fact the ones who do not trust or believe in the models (even their own!).

Research in the area is definitely ongoing, but the article summary presents such a basic overview that it makes it sound like subthreshold as a basic premise is some kind of new idea.

Now a subthreshold FPGA, that's nice if the interconnect is kept at the same low voltage. But then it would take a *really* long time to communicate. Although I guess you can throw in some sense amplifiers. But if the interconnect is high voltage, then it remains the major source of power loss. Is your Prof John Lach? I can't get to the seeming paper on my IEEE student account.

A more important property of the brain is that it is not as precise as a computer. The brain, and many other biological computations, perform their calculations in an analog manner that usually gets them "close enough" to the right answer. Digital designers think they need every bit of precision in a 64-bit floating point computation and they engineer the circuit to require it--this involves a lot of "over engineering." Of course, the really cool thing is that biology has "digital" circuits as well, when it needs it!

I'm not really an expert, I've just attended a lecture by Prof. Sarpeshkar at MIT. He's built some cool DSP devices modeled after the human ear. He has a new (text)book, "Ultra Low Power Bioelectronics: Fundamentals, Biomedical Applications, and Bio-inspired Systems."

It's really fascinating stuff, and I think is where low-power computation is really going to go: into a hybrid analog-digital domain. Subthreshold is cute in SPICE, but process variation is a huge barrier to using it on any kind of microprocessor or SoC sized chip.

You would be closer to say PNP = -NPN. Especially if you carefully define the - operator.