miratrix

I'm assuming you're talking about Platform / BSP side of the ugliness.

You have to look at the lineage of how things evolved to the current state - on the PC ecosystem, everything is already on enumerable buses (PCI, USB, etc) with standards (PCI, UEFI, etc) describing how it's all supposed to find what device is connected where and have it all work together. The incremental cost of opening that up to the public is thus fairly small since you need to build your platform to adhere to the standards that are already there anyway. That's how you get to being able to boot a kernel image on a random system or insmod a random driver you found and expect it to (mostly) work.

In the SBC/Embedded ecosystem, there really aren't any standards. Since internal topology of each SoC is different and the pace of new SoC releases is so high, there's no time for standardization - you throw in random IPs from bunch of different vendors, figure out how to connect it all together, and get it to the market. In this scenario, having something documented is actually a negative thing - once something is documented, people expect it to work the same way going forward. You can hide a lot of hardware deficiencies in binary blobs, something that's very difficult to give up. Thus, there's a huge disincentive to provide full hardware documentation. I'd imagine that in some cases, for licensed IPs, the SoC vendors may not even be allowed to do so even if they wanted to.

Things like DeviceTree is trying to nibble around the edges of this problem, but given the current state of things, it'll be a while yet as a lot of the building pieces doesn't even seem like it's in the picture yet.

On the grid tied solar inverter front - the spec sheet says the battery voltage is 350~450 V, so we're looking at 108 lithium ion cells (25 x 18650 cells?) at 400 VDC nominal. This is quite different from typical lead acid battery pack voltage of 12, 24, or 48VDC that's used for battery backup storage, so a lot of existing solar battery storage infrastructure may not even work... this means that people may need to buy a whole new set of supporting hardware to integrate this into the existing solar systems instead of being able to update the software on existing hardware.

Lithium Ion also has quite a different (and much less forgiving!) charging cycle that requires much more monitoring of things like temperature, though I'd imagine a lot of that would be built-in as a safety mechanism directly into the Powerwall.

What I've heard is that National Electrical Code becomes much more stringent on battery systems greater than 48V, with the line drawn at 48V due to it being used widely in the phone landline system. I'm not sure how true that story is, but I'd imagine extra care is probably warranted. 10kWh is about 9kg of TNT. :-)

Transponders have to be turned off while you're at the airport and while the plane's being serviced on ground. I think 777 has 2 transponders, so you also need the ability switch from one to the other. Lastly, I believe all electronics on the plane must be on a breaker circuit in case of electrical shorts so that pilots can isolate and turn off faulty circuits.

But you're right, ACARS (the system through which the engine information was routed - http://en.wikipedia.org/wiki/Aircraft_Communications_Address...) probably should be updated to add more information...

Wifi scanning is also pretty terrible for power consumption as you found out.

If you are on Android, my guess is that your phone was set to be connected to Wifi during sleep. You can control it by going to Wifi networks section -> menu -> Advanced -> Keep Wi-Fi on during sleep, then setting it to "Only when plugged in" or "Never".

If you're driving around with the phone set to leave the Wifi on during sleep, it'll be constantly going in and out of range of various Wifi connections. If the Wifi part is set for passive scan, then the processor needs to be kept up as the Wifi chip attempts to collect the BSSID of all the network it see and processor tries to figure out whether these networks have been seen or not. If it's set for active scan, then the Wifi needs to power up the radios to transmit beacons. Pretty bad news in either case, unfortunately.

The difference between DCH (the full-on high power state) and PCH (the lowest power, waiting-for-paging state) is about 2-orders of magnitude. Last time I measured, it was about ~100mA vs ~1mA (at ~3.7V) used by the radio. So, it's not couple of minutes of battery life, but rather _many_ hours of standby life instead. People usually aren't very happy when a fully charged phone dies overnight.

I've seen apps do some crazy things and it really has a significant effect in over-all battery life. A popular Android weather clock widget woke the phone up every minute to update the minute number on the graphics and updated the weather information every ~15 minutes (gps + radio!) which single handily crushed the standby battery life from multiple days to less than 8 hours.

Yes, I don't think _every_ decision should be based on minimizing the wake ups... but on the other hand, all developers should at least try to have as much understanding of the platforms that they're working on so that they know what trade-offs they're making with each feature they're adding.

I'm glad that Google has these videos available and that they're being picked up in places like HN.

The problem with $30k Tesla in 2018 that doesn't differ too much from Nissan Leaf... is that we already have the 2013 Nissan Leaf. :-)

I worked on electric vehicle space in early 2000s - there are many improvements for sure since then, but in the battery technology, not much has changed. 10 years ago, top of the line 18650 Li-Ion cell (same ones used in laptops and the Model S) weighed 46g, had capacities of 2.6Ahr, and cost about $10 a pop. Now, it weighs the same but have capacities of about 3.4Ahr and cost about $5. 30% improvement and half the cost is nothing to laugh at, but that also took 10 whole years!

The biggest problem with batteries is that they're chemistry-bound - you don't get the free twice-every-2-years type of thing that we're used to in computing world.

Even with the Nissan Leaf type of vehicle, the growth in battery capacity and more efficient / lighter chassis may result in extension of range to, say, 150 miles from 100 miles by 2018. Will that make it a no-compromise electric car? What would the no-compromise range be?

Looking at what Tesla has done, and what Elon has said (who actually very carefully said "sort of affordable" - http://greenenergyholding.blogspot.com/2013/08/teslas-next-e...) what's more likely is a new model starting at, say, $40k ($30k after tax credits) with fairly limited range, with really usable range starting at around $50k. Is that affordable? Probably not. But probably does fit the label of "sort of affordable".

The problem is that once you get down to ~$30k pure electric car, you're going to end up something that looks like the Nissan Leaf, even 5 years from now. There is no magical Tesla dust that allows them to circumvent the laws of physics and economics.

The problem is in the batteries - Tesla Model S batteries come in 60 and 85 kWhr capacities. Using the most generous specific energy estimates and the price estimates (265 Whr/kg and 2.5 Whr/US$ - http://en.wikipedia.org/wiki/Lithium-ion_battery), you're looking at 500 to 700 lb of extra weight and $24k~$32k due to batteries alone. Even if the price halves in 5 years, you can't make money spending up to half the price of the car in batteries alone.

As a premium car, Tesla can charge the extra money required for the large battery pack and things like all aluminum chassis in Model S. At the lowered price point, the revenue just is not there to justify these things.

This basically means that to hit the $30k price point, you're going to end up with a much smaller battery pack (like Leaf's 24kWhr battery pack) and much smaller car so that they can hit the (lowered) performance target in both the driving characteristics (acceleration, top speed, etc which depend greatly on curb weight) and range (weight and battery capacity).

If you look at the engineering trade-offs required to get to $30k pure electric car in 5 year timeframe, it's hard to imagine something drastically different from Nissan Leaf in range, size, and driving characteristics.

CPU is rather a small power of total platform power consumption these days. Switching x86 to ARM won't magically get you from 5 to 50 hours of active usage. If you compare MacBook Air and the new iPad, you'll see that the difference is actually rather small:

MacBook Air 11.6 - 35 WHr battery and 5 hours of Wifi Usage at 7 W [1] New iPad - 42.5 WHr battery and 10 hours of Wifi Usage at 4.25 W [2]

e-ink screen may make that last far longer... but if you've spent any time trying to use the e-ink Kindle browser, you'll quickly realize that the lack of fast refresh rate is a very difficult problem to solve in terms of usable UI.

[1] http://www.apple.com/macbookair/specs.html [2] http://www.apple.com/ipad/specs/

I think there will be performance gains to be had, especially in applications where concurrency has been 'bolted on' (akin to the Big Kernel Lock).

However, I think what makes this interesting is not the raw performance it provides, but the functionality that it exposes. As far as I can tell, TSX will allow sets of operations to be executed, then "rolled back" in case of conflicts. This could greatly improve performance of Java code within synchronized blocks, for instance, or provide much faster hardware implementation of the software transaction memory model in Clojure.

I believe the biggest benefit of this will be making multi-threaded programming easier to get right, and get decent performance to boot. And if these constructs are supported natively in languages and frameworks, everyone will benefit from having 4- 8- or 16- cores.

"Apple typically asks suppliers to specify how much every part costs, how many workers are needed and the size of their salaries. Executives want to know every financial detail. Afterward, Apple calculates how much it will pay for a part. Most suppliers are allowed only the slimmest of profits."

"Many major technology companies have worked with factories where conditions are troubling. However, independent monitors and suppliers say some act differently. Executives at multiple suppliers, in interviews, said that Hewlett-Packard and others allowed them slightly more profits and other allowances if they were used to improve worker conditions."

The article clearly explains that Apple management does care, but that their drive for secrecy and control makes it much more difficult for them to affect change. Maybe he typed it on an HP computer instead.

The papers I've seen point to values larger than 15~30% - I've seen ~50% cited for geometries as large as 65nm, only to get worse as we go to even smaller feature sizes. [1]

Threshold voltage is not really an effective knob, unless you assume that the feature size to be a knob and go against Moore's law, or that brand new, once in 10-years process innovation is a knob that designers can pick out of a hat. I don't think anyone's clamoring for return to 130nm parts on a smartphone. At each new process node, you're going to lose out on the amount of control you'll have over Vth.

This is basically what Intel did with the tri-gate transistors which gives them longer lease on life until they bump against subthreshold leakage. TSMC is on their first generation high-k metal gates, and still a process node or two away before jumping over to the tri-gate party.

1. http://www.eetimes.com/design/eda-design/4211228/Overcoming-...

Leakage power is actually very significant part of the total power usage [1] and one of the bigger reasons why Intel developed the tri-gate technology [2].

Active power is the one that's related to the frequency (P ~= CV^2f). Leakage power will "leak" even if the transistor is not switching.

1. http://www.eetimes.com/electronics-news/4215605/Leakage-powe... 2. http://realworldtech.com/page.cfm?ArticleID=RWT050511195446

You're going to be I/O bound (network or disk), memory bound, or compute bound. It's hard to imagine the Redstone systems besting Xeon based servers in any of the three.

Not quite true - Greek bonds did not have significantly higher interest rates than other Euro denominated bonds.

Greek bond chart: http://www.bloomberg.com/quote/GGGB1YR:IND/chart German bond chart: http://www.bloomberg.com/quote/GDBR1:IND/chart

Go back out 3 years, and you'll see that as late as December 2009, the yield spread was minor, and that it didn't start to really diverge until July of this year.

I think it's more that the "mainstream" computing has moved on from desktops to laptops.

Instead of targeting the latest and greatest design at 130W/90W TDP desktop parts and downsizing it to a laptop, they've turned it around and is starting to target 35W TDP as their main platform, then upping the power to turn it into a desktop part.

Since power consumption and heat dissipation is becoming an issue also at their top-of-the-line server market, it probably makes much more sense to design things that way. My guess is that high density server design at this point has more in common with laptop-esque power and heat constraints than those of, say, high-end workstations.

If you're interested in these patent issues, you should add FOSS Patents (http://fosspatents.blogspot.com/) to your RSS reader.

Florian has the list of patents being asserted by HTC and some analysis of them at http://fosspatents.blogspot.com/2011/09/these-are-patents-go...

I think you may have missed one of the central point that Urs was trying to make:

"Software development costs often dominate a company’s overall technical expenses, so forcing programmers to parallelize more code can cost more than we’d save on the hardware side."

There could be savings to be had by having a very smart scheduler that knows all about what kind of workload a given piece of task is by analyzing the code and dispatching it correctly. As you mentioned, though, that's not an easy problem to solve, and will also be a part of the software development cost.

From the programmer's point of view, that'll be yet another variable out of their control that may break the computing abstraction that makes these massive parallel machines possible.

Something based on the Cortex-M series (http://www.sparkfun.com/products/10664) probably is a better ARM starter board for someone who's getting started on the embedded stuff. Cortex-A series ARMs are completely different beasts in terms of complexity.

mSv stands for milli-Sievert, and uSv is micro-Sievert. 4000 uSv would be equivalent to 4 mSv, which is where Randall has it listed.

You can also use the "dirs" command (I think part of bash as well) that tells you the state of the stack. If you set the -v option, you can get the depth of different directories, and you can just do pushd +N to jump to the specific directory.

The group is setup to allow users to respond to all... and there are about 30000 users on the mailing list. It's fun for a bit, but I'm guessing it was meant to be an announcement only list. Any googlers up?

The problem is that Facebook's claiming that email is just another piece of metadata about a user. However, from Google's point of (and rest of the non-Facebook web), email is not a metadata, but the key identifier around which all of the services know which "John Smith" the given user is.

If I'm building anything interesting and want to play outside the Facebook walled garden, the Facebook ID doesn't really get me anything - it's like someone giving me a currency from a random country that I never intend to visit.

Unfortunately, even Facebook itself treats the email address as an identifier data (what do you need to use to log in to Facebook? Email address and password). It's a little disingenuous for them to turn that around and say that it's a metadata that's part of the user's profile, as opposed to the only unique, persistent, and widely used identifier that we currently have on the web.

Looks like Archos has a 7 inch tablet that they sell for $199, though it doesn't have 3G access. Archos has been around for a while and are known to build fairly solid hardware, so this isn't some drive-by-night operation hawking crap on late-night informercial either.

http://www.archos.com/products/ht/index.html?country=us&...

edit: er, apparently it still runs android 1.5...

The differentiating factor over the typical webcam software is the fact that the data is stored in the cloud, and can be retrieved and replayed at any time, right?

If you want to get a lot of eyeballs looking at it, what about finding something that people will watch, will want to "rewind", and will want to share?

People love puppies, so what about finding a local breeder and asking them if they'd mind having a camera there in return for showcasing them? And allow people to watch not only the current streaming version, but the old archived footage and vote & share their favourite moments? It doesn't have to be puppies, but anything that people enjoy watching... though population that might be looking at puppies might have overlaps with, say, population that might have kids and may be in the market for a nanny-cam or something...

That sounds a lot like expect ( http://en.wikipedia.org/wiki/Expect ) unless I've missed something. If you use autoexpect, it'll even automagically generate the script for you by capturing what you type in to the shell.

Gmail already does this - if you have the List-Unsubscribe header set up, when someone clicks on the "Spam" button, it asks them whether they want to unsubscribe as well. If they say "yes", an email gets sent to the unsubscribe address with "Unsubscribe" as the subject.

Took me a minute to figure out what was going on - the ability to go back in time of a live video feed is pretty neat, though it doesn't always seem jump to a keyframe, resulting in video artifacts.

Seems like a neat idea - instead of buying one of those expensive video multiplexer with bunch of cameras, just subscribe to a service that does all of the video storage and processing for you. How much BW does each camera consume? If I was using this for something important, I'd be afraid of losing footage due to internet connection issues.

As I see it, the real power of email comes from the inherent queuing nature - it allows you to decouple your schedule from demands of others.

Being "realtime", especially if the senders have the expectation that the message is realtime, means necessarily losing that queuing nature which greatly diminishes email's flexibility and resilience.

The biggest problem with realtime is that you _need_ to implement some sort of access control, or otherwise you'll be inundated and overwhelmed with messages. If we turn email to realtime, we'll necessarily need to build the access control (or some sort of super filter) into it, and that basically shuts down the open nature of email. You can argue that open email is good (emailing Steve Jobs) or bad (spams) but it _is_ something that has real value.

Remember to get their name and address, as well EIN / SSN so that you can actually fill out the fields in the 1099 form. And even if it's below $600, you _might_ buy from them before the year-end, so you need to record the amount in case the total aggregate amount for the year goes above $600.

This requirement is just plainly insane, but at least IRS also agrees that it's insane ( http://www.irs.gov/newsroom/article/0,,id=225270,00.html )