The story of Chris Knight, living in isolation in the woods of Maine for 27 years.
'Anyone who reveals what he's learned, Chris told me, is not by his definition a true hermit. Chris had come around on the idea of himself as a hermit, and eventually embraced it. When I mentioned Thoreau, who spent two years at Walden, Chris dismissed him with a single word: “dilettante.”'
'But still, I pressed on, there must have been some grand insight revealed to him in the wild…”Get enough sleep.”'
I don’t want to brag, but I’ve been telling that people all along and I didn’t have to live alone in the woods for decades.
Applied game theory 101: Valve’s Steam Summer Sale involves a meta game with teams of Steam users competing for daily prizes. On Reddit the players join together to take turns winning daily. Valve gets wise and performs an existential attack, changing the rules to make it harder for players to want to coordinate.
Still, that all the players joined together to game the system gives me hope for humanity. Its a self organized solution to a tragedy of the commons problem. Only in this case the tragedy is by design and is updated to be more tragic.
More than 90% of Americans believe that the US government is unduly influenced by money, and the Mayday.US super PAC is raising $5M to fund the election campaigns of politicians who’ll pledge to dismantle super PACs and enact other campaign finance reforms. They raised more than $1M in 30 days last month, and this month, the goal is $5M. It’s the brainchild of Lawrence Lessig, who’s going to run prototype the project by running five electoral campaigns in 2014, and use the lessons of those projects to win enough anti-corruption seats in 2016 to effect real change.
Again, I’m not able to contribute to Mayday.US, because I’m a Canadian and Briton. But I ask my American friends to put in $10, and promise that I’ll put CAD1000 into any comparable Canadian effort and/or £1000 into a comparable UK effort. We all win when countries embrace evidence-based policy guided by doing what’s best for its citizens, rather than lining the pockets of corrupting multinationals.
Please reblog!
Some time back while I was working on getting the Javascript Windows Store app platform running on Windows Phone (now available on the last Windows Phone release!) I had an interesting bug that in retrospect is amusing.
I had just finished a work item to get accessibility working for JS WinPhone apps when I got a new bug: With some set of JS apps, accessibility appeared to be totally broken. At that time in development the only mechanism we had to test accessibility was a test tool that runs on the PC, connects to the phone, and dumps out the accessibility tree of whatever app is running on the phone. In this bug, the tool would spin for a while and then timeout with an error and no accessibility information.
My first thought was this was an issue in my new accessibility code. However, debugging with breakpoints on my code I could see none of my code was run nor the code that should call it. The code that called that code was a more generic messaging system that hit my breakpoints constantly.
Rather than trying to work backward from the failure point, I decided to try and narrow down the repro and work forwards from there. One thing all the apps with the bug had in common was their usage of WinJS, but not all WinJS apps demonstrated the issue. Using a binary search approach on one such app I removed unrelated app code until all that was left was the app's usage of the WinJS AppBar and the bug still occurred. I replaced the WinJS AppBar usage with direct usage of the underlying AppBar WinRT APIs and continued.
Only some calls to the AppBar WinRT object produced the issue:
var appBar = Windows.UI.WebUI.Core.WebUICommandBar.getForCurrentView();
// appBar.opacity = 1;
// appBar.closeDisplayMode = Windows.UI.WebUI.Core.WebUICommandBarClosedDisplayMode.default;
appBar.backgroundColor = Windows.UI.Colors.white; // Bug!
Just
setting the background color appeared to cause the issue and I didn't even have to display the AppBar. Through additional trial and error I was blown away to discover that some colors I would set
caused the issue and other colors did not. Black wouldn't cause the issue but transparent black would. So would aqua but not white.
I eventually realized that predefined WinRT color values like Windows.UI.Colors.aqua would cause the issue while JS literal based colors didn't cause the issue (Windows.UI.Color is a WinRT struct which projects in JS as a JS literal object with the struct members as JS
object properties so its easy to write something like {r: 0, g: 0, b: 0, a: 0}
to make a color) and I had been mixing both in my tests without realizing there would be a difference.
I debugged into the backgroundColor property setter that consumed the WinRT color struct to see what was different between Windows.UI.Colors.black and {a: 1, r: 0, g: 0, b: 0}
and
found the two structs to be byte wise exactly the same.
On a hunch I tried my test app with only a reference to the color and otherwise no interaction with the AppBar and not doing anything with the actual reference to the color:
Windows.UI.Colors.black;
. This too caused the issue. I knew that the implementation for these WinRT const values live in a DLL and guessed that something in the code to create these
predefined colors was causing the issue. I debugged in and no luck. Now I also have experienced crusty code that would do exciting things in its DllMain, the function that's called when a DLL is loaded into the process so I tried modifying my
C++ code to simply LoadLibrary the DLL containing the WinRT color definition, windows.ui.xaml.dll and found the bug still occurred! A short lived moment of relief as the world seemed to make
sense again.
Debugging into DllMain nothing interesting happened. There were interesting calls in there to be sure, but all of them behind conditions that were false. I was again stumped. On another hunch I tried renaming the DLL and only LoadLibrary'ing it and the bug went away. I took a different DLL renamed it windows.ui.xaml.dll and tried LoadLibrary'ing that and the bug came back. Just the name of the DLL was causing the issue.
I searched for the DLL name in our source code index and found hits in the accessibility tool. Grinning I opened the source to find that the accessibility tool's phone side service was trying to determine if a process belonged to a XAML app or not because XAML apps had a different accessibility contract. It did this by checking to see if windows.ui.xaml.dll was loaded in the target process.
At this point I got to fix my main issue and open several new bugs for the variety of problems I had just run into. This is a how to on writing software that is difficult to debug.
The original open source Wifi Hotpot for Windows 7, Windows 8 and Windows Server 2012!
Free open source software based router you can run on Windows to wirelessly share your Internet connection with other devices
Guardian - Secrets, lies and Snowden’s email: why I was forced to shut down Lavabit
"For the first time, the founder of an encrypted email startup that was supposed to insure privacy for all reveals how the FBI and the US legal system made sure we don’t have the right to much privacy in the first place"
RT @PeerProd In Europe, encrypted traffic went from 1.47% to 6.10%, and in Latin America, it increased from 1.8% to 10.37%
http://www.wired.com/2014/05/sandvine-report/ #NSA
A reminder that those Doritos you love are trash:
Shortly after Disneyland opened in 1955, the founder of Frito-Lay got permission from Walt Disney to open a restaurant in Frontierland with a Mexican-ish theme. “Casa de Fritos” was, unsurprisingly, all about the Fritos. Customers got free Fritos, and Fritos were incorporated into many of the dishes. Fritos were dispensed by an animatronic vending machine that featured the terrifying “Frito Kid”asking his assistant “Klondike” to bring the bag up from a mineshaft. I guess the conceit is that Fritos were mined by Forty-Niners?
Casa de Fritos contracted their tortilla production to a company called Alex Foods. One of the salesmen from Alex Foods, making a delivery to Casa de Fritos, noticed stale tortillas in the garbage and gave the cook a little tip: fry them and sell them as chips instead of throwing them away. Casa de Fritos began making these fried, seasoned chips to enormous success, but didn’t report this new menu item to the Frito-Lay company.
Eventually Frito-Lay found out what they were doing with the chips, packaged them, and sold them by the truckload. See, dumpster diving works out sometimes!
List of useful free or CC licensed photography and icon sites.
'Please Contact Us': It's Been a Tough Week for the Nobel Prize's Twitter Feed
Tales of temporary rejection from an organization not used to being ignored.
WinRT (JS and
C++)
|
JS Only
|
C++ Only
|
.NET Only
|
|
Parse
|
|
|||
Build
|
||||
Normalize
|
||||
Equality
|
|
|
||
Relative
resolution
|
||||
Encode data for
including in URI property
|
||||
Decode data extracted
from URI property
|
||||
Build Query
|
||||
Parse Query
|
In IE10 and other new browsers one may create MessageChannel objects that have two MessagePorts each connected (w3c spec calls it entangled) to one another such that postMessage on one port results in the message event firing on the other. You can pass an array of ports as the last parameter to postMessage and they show up in the ports property of the message event arg.
The postMessage here is like the worker postMessage and unlike the window and iframe postMessage in that it applies no origin checking:
Unfortunately the origin isn't an optional parameter at the end to make the two postMessages have the same signature.
On the event handler side, the event arg always has an origin property. But in the no origin case it is always the empty string.
There is also a source property on the message event arg which if set is an object that has a postMessage property allowing you to post back to your caller. It is set for the origin case, however, in the no origin case this property is null. This is somewhat reasonable because in the case of MessagePort and Workers there are only two endpoints so you always know the source of a message implicitly. Unlike the origin case in which any iframe or window can be calling postMessage on any other iframe or window and the caller is unknown. So not unreasonable but it would be nice if the source property was always set for consistency.
When a MessageChannel is created it has two MessagePorts, but until those ports are started they will queue up any messages they receive. Once started they will dispatch all queued messages. Ports don't have to be started to send messages.
A port may be started in two ways, either by explicitly calling the start method on the port, or by setting the onmessage callback property on the port. However, adding an event listener via addEventListener("message", does not start the port. It works this way in IE and Chrome and the spec states this as well.
The justification is that since you can have only one callback via onmessage that once set you must implicitly be ready to receive messages and its fine to start the port. As opposed to the addEventListener in which case the user agent cannot start implicitly because it doesn't know how many event listeners will be added. I found Hixie stating this justification in geoloc meeting notes.