After installing the GMs to Sierra and Friends I was eager to try out the Auto Unlock feature with the Watch as passwords generally suck and re-entering them time and again sucks more.
With all my devices on the same Apple ID and updated, I went to the Security prefs on the Mac and lo … no option for it. After reading around I learned all the devices must be marked as Trusted in iCloud, which means you need Two-Factor Authentication (not Two-Step). I set this up and re-added each device to iCloud until they were marked appropriately. Still no option on the Mac.
Then I read around a little and discovered the requirements for this feature, which I couldn't find on Apple's site anywhere. While early release notes to the betas said any 2013 Mac would work, it turns out that only mid-year and later models will work — specifically those with the 802.11ac network card.
I ain't upgrading for this. Luckily, other folks have some solutions for this that work with less-stringent requirements on how recently your Apple tithe was paid, such as Knock and MacID.
Is It Illegal to Make Your Spouse Ride on the Roof of the Car? | Lowering the Bar
This question arises from the recent arrest of a Florida man (credit: The Smoking Gun) after he was stopped by a police officer who wished to inquire as to why there was a woman clinging to the roof of his car. The answer to that question, as you might expect, turned out to be complicated.
State: Answers were erased on 14,220 STAAR tests | www.mystatesman.com:
State officials are threatening to reconsider a $280 million contract with its testing vendor after answers to 14,220 state standardized tests were erased because of a computer glitch last week.
Also, the bridge was designed as a suspension bridge, but nobody actually knew how to build a suspension bridge, so they got halfway through it and then just added extra support columns to keep the thing standing, but they left the suspension cables because they're still sort of holding up parts of the bridge. Nobody knows which parts, but everybody's pretty sure they're important parts.
Every project I've ever worked on has this smell somewhere.
People like to think Microsoft is the dean of proprietary software companies. Nonsense! Microsoft is making serious investments in open-source software. Apple, though, now there's a company that likes to lock down its code.
Apple's Swift Comes to Linux - ZDNet
Likes to lock down their code? WTH? Pay attention to that which you critique. The OS is open source, the compiler has always been open source, WebKit is open source, the core frameworks are open source, and they publish all changes to GPL code as they should. Seriously, what's your standard here, especially when comparing to MS?
I should expect this from ZD though. I think they're beating CNet to the bottom.
The issue is larger than the folks running the show can fix. Their members vote based on what they see as talent. Their membership is not at all diverse. Even this, though, isn't in their control. They mainly have A-level members with some scattering of Bs. Folks at that level trend towards the pale end of the spectrum as a product of the viewership's perceived preferences ("Ain't no white family going to see a movie with a black lead!" uhh, Lethal Weapon? The Matrix? A hundred others?)
So if we want a villain – and who doesn't? – it's the casting and hiring directors who are using outmoded descriptions of the viewership (from their producers and other management) from god-knows-when that limit the influx of diverse talent into the industry to begin with.
Fix that and then the cast and crews become diverse (as the people on-screen in the theaters become more diverse). Then they get their membership and vote. Then the nominees reflect this.
It's a huge problem, and not at all fair for anyone on any side to blame them for what their members chose. It's like blaming the county clerk for who won a political race. The voters chose. Fix the voters.
The silent trade: universal objective ethics in action:
Once upon a time, back during the Age of Exploration, there was a marvellous practice called the “silent trade”. It was a solution to a serious coordination problem between groups who had no languages in common, or distrusted each other so much that they refused to come within range of each others’ weapons.
I do love interesting bits of trivia.
… it could always be Mac OS 9.
An introvert raising an extrovert child might make for an interesting sitcom. I've spent the last two days at home with the boy on vacation and I've gotten to the point where I've answered every question he's asked for the past two hours with "meh".
It's like he exhales in English.
I'm working an intermediary library in Python that turns a fair number of normal databases and database-like stores into simple key-value stores. There's a long story of why, but it does it have an actual use case outside of "because I can" (though, the symlink backend is pure, unadulterated "because I can").
For the SQLite store I was running into transaction issues here and there. At seemingly-random times data wouldn't save or I'd get an error saying a transaction hadn't been started when I tried to commit. So, I did some research.
John CS - Transactions with Python's sqlite3 Package:
By automatic transactions here I am not referring to SQLite's built-in behavior of wrapping data-changing operations in transactions. Rather, I am speaking of the Python module's special behavior where it actually executes BEGIN and COMMIT statements on your behalf.
A transaction is automatically started (ie: a BEGIN is executed) when all of the following conditions are met:
The BEGIN statement will be concatenated with whatever value is in isolation_level. For example, if isolation_level was equal to DEFERRED, the statement executed when the above conditions are met is BEGIN DEFERRED.
- The isolation_level is not None. 
- The Connection object thinks a transaction has not already been started.
- An UPDATE, DELETE, INSERT, or REPLACE statement is being executed. 
Introduction to SQLite in Python | Python Central:
Please remember to always call commit to save the changes. If you close the connection using close or the connection to the file is lost (maybe the program finishes unexpectedly), not committed changes will be lost.
11.13. sqlite3 — DB-API 2.0 interface for SQLite databases — Python 2.7.11 documentation:
If you want autocommit mode, then set isolation_level to None.
Otherwise leave it at its default, which will result in a plain “BEGIN” statement, or set it to one of SQLite’s supported isolation levels: “DEFERRED”, “IMMEDIATE” or “EXCLUSIVE”.
The lesson learned here comes down to these points:
- Python's sqlite3 module conforms to the broken Python PEP for database access which mandates that there's always a transaction in play and your only control over it is to commit or roll back.
- DB modules are supposed to keep track of the current transaction state internally and not offer a
- The value of
connection.isolation_level can be set to
None to turn off all this or to
EXCLUSIVE to turn it on. The text in
isolation_level is sent with the
BEGIN statement to SQLite, so all of those carry SQLite's meaning:
DEFERRED - Get a shared lock on the first statement. Get an exclusive lock only when a DML statement is used. (Default)
IMMEDIATE - Get a write lock immediately. Others can read, but writes will be blocked (timeout applies).
EXCLUSIVE - Get an exclusive lock immediately. Others cannot even read.
- You can turn this behavior off, but then you have to fall back to 100% manual transaction management, and in many cases this can be done very wrong and cause random slowdowns or data loss (if you aren't well-versed in transactional databases).
- Due to how sqlite3 handles threaded and multi-process access, there's a timeout on getting the lock to start a DML statement, and the default is five seconds. This can lead to some interesting situations.
So, in short: abide by the PEP gods and presume a messed-up transaction environment that you can only control with
rollback() or turn it all off and wing it.
In the end, I chose to manually commit at key points in order to both ensure the data was written but also for the side effect of starting a new transaction.
That, folks, is when you know you've made a broken API. Side effects should never be the goal of a line of code, but due to the API design they must be here.