Just a test post, to see if 301 redirects are working properly.
The best explainer I’ve yet seen on the SF housing issue, by Kim-Mai Cutler: How Burrowing Owls Lead To Vomiting Anarchists (Or SF’s Housing Crisis Explained).
Long and detailed, it’s great for a lazy Sunday coffee and reading session.
And an op-ed in the NYT about subsidizing suburbs: America’s Urban Future by Vishaan Chakrarbati.
I am not arguing that people should not live in suburbs. But we shouldn’t pay them to do so, particularly now that our world and the desires of our population are evolving.
Cohere’s 4th anniversary alumni catchup.
No, I do not have a google alert on my own name. That would be ridiculous.
One of the key design goals we had in mind when we set out to create Ubuntu for phones and tablets (henceforth abbreviated here as Ubuntu Devices (vs Ubuntu Desktop)) was how to balance continuing our rich heritage of downstreams, be they community remixes or commercial products, against the idea of preventing platform API and UI fragmentation, which is the Android antipattern.
A while back, my boss Victor wrote a blog entry titled Differentiation without fragmentation which gives a key insight as to why fragmentation occurs:
Fragmentation occurs when the software platform fails to provide a supported mechanism to differentiate.
Victor then goes on to describe our Scopes framework which is a core design concept that spans implementation, functional, and visual layers to enable our downstreams to differentiate.
Part of my job is making what Victor says actually come true, and as we started thinking through the actual mechanics of how our downstreams would start with a default Ubuntu Device image and end up with a customized version of it, we realized that the nuts and bolts of what an OEM engineer or enthusiastic community member would have to learn and understand about our platform to actually make a working device image were too complex.
So we roughed out some ideas and after several months of iterating in private, I’m pleased to announce the preview of the Ubuntu Savvy phone customization suite. It consists of several parts:
- Source branch and test suite, open for all to see: bzr branch lp:savilerow
- Readable documentation, from big picture down to nitty grittys. You can preview it for now at people.c.c/~achiang/ubuntu_savvy but it will eventually move to developer.ubuntu.com
- Shiny tools, some prototyped, some planned. Preview at lp:~achiang/savilerow/tailor-poc but will eventually move to its own LP project
The prototype of Tailor, our tool to manipulate the Savvy source tree and deploy to your phone is definitely in early stages. But click on the screenshots below to get a sense for where we are going. We want it to be painless and fun for anyone to make their own version of Ubuntu for devices in an officially supported manner.
If you are interested in learning more about our plans or you have ideas for ways that you’d like to customize your version of Ubuntu or you’re interested in improving code, tests, or docs, please come to our vUDS session.
Carrier/OEM Customizations on 2014-03-13 from 15:00 to 15:55 UTC.
A final note, Ubuntu Savvy builds upon a lot of work, from the fine folks in UE who helped design a flexible, decoupled image architecture, to the SDK team for providing some nice QML code for us to re-purpose, and to my entire team, both present and emeritus (such as mfisch and sfeole). Thanks to all.
We invite the broader Ubuntu community to help tinker with and tailor Ubuntu.
Upward and onward!
This year was my first time attending MWC and it was quite the experience. I’ve been to some conferences before, but the sheer scale of this one was amazing.
And although it was my first time attending in person, it certainly wasn’t the first time I helped the team prep for the show on the technical side. A hectic several weeks of landing fixes and features, to an installation party on Sunday night, and rushing to the booth early Monday morning to do a final pass of updates before doors opened at 9am, the team on the ground with super support from the team on the homefront worked until the literal last minute to produce the best software build we could for a week of intensive demos. It wasn’t perfect, but no demos ever are, and I was extremely proud of the end result.
My job was to be a booth babe and give demos of Ubuntu phones and tablets to interested passers-by, but I lost my voice on Monday (possibly laryngitis) and was thus relegated to back room tech support for the rest of the week.
There was also an unfortunate incident with mussels and food poisoning that I’ll not expand on here, but if you want full details, talk to my hotel roomie Cimi who got the Full 3D/HD experience at 4am. Sorry Cimi!
After the crazy week, Cimi and I spent the weekend decompressing by taking in the sights, before starting our second week in Barça, where the plan was to work remotely whilst eating as much jamón ibérico as humanly possible.
The last time I was in town, I saw quite a lot of the major tourist attractions (thanks to turbo-mom who just pushed our family to maximize every moment), but two things we missed were the Miró museum and Montserrat. So that was Saturday and Sunday, respectively, and I’m pleased to report both were worth the wait.
In fact, I hadn’t realized what a fan of Miró I was, and speed-bingeing on the Wikipedia article on the Spanish civil war made the experience all the richer.
The remainder of the week was fairly nondescript. We enjoyed hanging out in the quiet Sant Andreu neighborhood and doing our interpretation of local life, namely sleeping in until 10am, working a bit, enjoying siesta from 1500 — 1800, eating tapas, maybe working a bit more, and saving everything else for mañana.
All the photos from the trip are in barcelona 2014, and to wrap it up, my first ever attempt at video creation is below.
Two good articles came across my plate recently. If you need some good lunch time reading, give these a spin.
This article is from 1999 (!!) and I think provides very useful context to the current housing debates raging in SF and SV. I don’t think SF Weekly has ever been accused of having a conservative bias.
Welcome Home –
How shortsighted neighborhood activism fuels the city’s housing crisis, and pushes the best of San Francisco deeper and deeper into the suburbs
A more current article analyzing the end game for Taiwan. It made me feel depressed, although I can’t rationally say why.
In both git and bzr, each branch you clone is a full copy of project’s history. Once you have downloaded the source control objects from the remote location (e.g. github or launchpad), you can then use your local copy of the repo to quickly create more local branches.
What if another user has code in their branch that you want to inspect or use?
In git, since it’s common to have many logical git branches in the same physical filesystem directory, the operation is conceptually a simple extension of the default workflow, where you use “git checkout” to switch between logical branches.
The conceptually simple extension of the workflow is to add the location of the remote repo to your local repo and download any potentially new objects you don’t already have.
Now you have access to the new branches, and can switch between them with “git checkout”.
In command sequences:
git remote add alice https://github.com/alice/project.git git remote update git checkout alice/new_branch
This workflow is great if project.git is very large, and you have a slow network. The remote update will only download Alice’s objects that you don’t already have, which should be minimal, comparatively speaking.
In bzr, the default workflow is to have a separate physical filesystem directory for each logical branch. It is possible to make different branches share the same physical directory with the ‘colo’ plugin, but my impression is most people don’t use it and opt for the default.
Since different bzr branches will have different directories by default, getting them to share source control objects can be trickier especially when a remote repo is involved.
Again, the use case here is to avoid having to re-download a gigantic remote branch especially when perhaps 98% of the objects are the same.
I read and re-read the `bzr branch` man page multiple times, wondering if some combination of –stacked, –use-existing-dir, –hardlink, or –bind could do this, but I ended up baffled. After some good clues from the friendly folks in the #bzr irc channel, I found this answer:
I used a variation of the second (non-accepted) answer:
bzr init-repo ../ bzr reconfigure --use-shared
I was then able to:
cd .. bzr branch lp:~alice/project/new_branch cd new_branch
The operation was very fast, as bzr downloaded only the new objects from Alice that I was missing, and that was exactly what I wanted. o/
- When you issue “bzr init-repo ../” be sure that your parent directory does not already contain a .bzr/ directory or you might be unhappy
- Another method to accomplish something similar during “git clone” is to use the –reference switch
- I don’t know what would have happened if you just issued “bzr pull lp:~alice/project/new_branch” inside your existing branch, but my intuition tells me “probably not what you want”, as “bzr pull” tends to want to change the working state of your tree with merge commits.
- Again contrast to git, which has a “git fetch” concept that only downloads the remote objects without applying them, and leaving it up to the user to decide what to do with them.
When you use GPS on your mobile device, it is almost certainly using some form of assistance to find your location faster. Attempting to only use pure GPS satellites can take as long as 15 or 20 minutes.
Therefore, modern mobile devices use other ambient wireless signals such as cell towers and wifi access points to speed up your location lookup. There’s lots of technology behind this, but we simplify by calling it all AGPS (assisted GPS).
The thing is, the large databases that contain this ambient wireless information are almost all proprietary. Some data collectors will sell you commercial access to their database. Others such as Google, provide throttled, restricted, TOS-protected access. No one I am aware of provides access to the raw data at all.
Why are these proprietary databases an issue? Consider — wireless signals such as cell towers and wifi are ambient. They are just part of the environment. Since this information exists in the public domain, it should remain in the public domain, and free for all to access and build upon.
To be clear, collecting this public knowledge, aggregating it, and cleaning it up requires material effort. From a moral standpoint, I do think that if a company or organization goes through the immense effort to collect the data, it is reasonable and legitimate to monetarily profit from it. I have no moral issue there1.
At the same time, this is the type of infrastructural problem that an open source, crowd sourced approach is perfectly designed to fix. Once. And for all of humanity.
Which is why the Mozilla Location Service is such an interesting and important project. Giving API access to their database is fantastic2.
If you look at the map though, you’ll see lots of dark areas. And this is where you can help.
If you’re comfortable with early stage software with rough edges, you should install their Android app and help the project by going around and collecting this ambient wireless data.
Note: the only way to install the app right now is to put your Android phone in developer mode, physically connect a USB cable, and use the ‘adb’ tool to manually install it. Easy if you already know how; not so easy if you don’t. Hopefully they add the app to the Play store soon…
The app will upload the collected data to their database, and you can watch the map fill in (updated once a day). If you need more instant gratification, the leaderboard is updated in near realtime.
You might not want to spend time proofreading articles on Wikipedia, but running an app on your Android device and then moving around is pretty darn easy in comparison.
So that’s what I did today — rode my bike around for open source ideals. Here’s the map of my ride in Strava:
I think I collected about 4000+ data points on that ride. And now the map in San Francisco looks like this:
Pretty neat! You can obviously collect data however you like: walking around, driving your car, or taking public transportation.
For more reading:
- Introducing the Mozilla location service
- Soledad Penadés’s blog about MLS
- wiki page
- how Mapbox helped with this project
1: well, I might quibble with the vast amount of resources spent to collect this data, repeated across each vendor. None of them are collaborating with each other, so they all have to individually re-visit each GPS coordinate on the planet, which is incredibly wasteful.
2: you can’t download the raw database yet as they’re still working out the legal issues, but the Mozilla organization has a good track record of upholding open access ideals. This is addressed in their FAQ.
A little something I worked out before the holiday break was to start figuring out how to make it easy to target Ubuntu Touch if you run OSX.
There are quite a number of dependencies that must be resolved before you can actually write and deploy an Ubuntu Touch app from OSX, but for now, simply installing a device is a good start.
Combined with our recently announced dual boot instructions, we’re trying to remove as many barriers to entry as possible.
Happy new year!
A new day, a new #techbus protest. This time it’s larger, more organized, and less theatrical.
I have to admit, as silly as it sounds for activists to disrupt the buses to make their larger point, I actually admire their reasoning and their methods. I agree with the activists that annoying individual employees, keeping the issue in the forefront of their minds, and preventing them from continuing to live in their privileged bubbles is a desirable end goal in and of itself.
[To be crystal clear, I don't place any blame on the individual employees themselves. There are far larger structural issues at play and in the end, they are also pawns. (Well, maybe more like rooks considering their enhanced power...)]
The risk, of course, is alienating people you want on your side. But the upside of this strategy is that tech nerds tend to be quite reasonable once confronted with facts, and it’s not altogether inconceivable that they/we would adopt at least parts of the activists’ platform, either as individuals or adding to some of the internal debate that’s surely occurring inside the tech companies.
“It’s an invitation for them to be part of the solution,” said organizer Fred Sherburn-Zimmer. Sherburn-Zimmer and her collective want to see big tech companies like Google get involved in overthrowing the state’s Ellis Act – which allows a landlord to go out the rental business and evict all the tenants, usually before or after the sale of the property. Or to somehow help restrict the rise of rents near shuttle stops. Paying for the use of the stops, of donating to the city or to housing rights organizations would also be a step in the right direction, she said.
Speaking of adopting planks in a platform, I can state that at this point in my evolution of thinking about the problem…
- I can easily agree with the idea of companies donating to housing rights organizations
- I’m less convinced of paying the city to use the public stops but could change my mind given good examples of prior art
- The idea of somehow restricting rents near shuttle stops is ludicrous and should be dropped immediately to maintain any sort of credibility when engaging the tech companies
- And I am not yet sure how I feel about the Ellis act…
The things about Ellis that conflict in my mind…
- It seems to be designed to allow property owners to do what they want with their own property, and the theory is that owners would use it to live in houses they themselves own. I’m ok with that theory.
- In practice, it seems that landlords use it to evict poor tenants, convert rental units to condos, and then re-rent them to richer tenants. I’m very much not ok with that abuse of people without power.
- In theory, “landlords have the unconditional right to evict tenants to go out of business”
- In practice, “many buildings Ellised will come back as re-rentals—at higher rents”.
That sounds like a pretty fucked up law that needs to be fixed.
A somewhat discordant sentence from the above cited page says:
The first rule of an Ellis is not to panic but to become resolved to fight for your home.
My biggest issue in all of this debate revolves around the concept of “yours”. Whose home is it, anyway? As a recovering former libertarian, that the answer is no longer black and white to me.
One of the better explanations I’ve read about the history of how San Francisco ended up where it is comes from Matt Yglesias’s Slate article: Build More San Francisco.
There’s zero possibility for sprawl inside the city of San Francisco (it’s all built out), so you either build up or you just don’t build. And the preference, apparently, is to not build. That way you preserve the existing physical plant and handle “affordability” as a question of allocating an increasingly scarce resource.
Understanding that entrenched power players controlling San Francisco’s public policy view the low density as a positive thing, and that supply simply needs to be allocated properly to the right people is the key to understanding why we don’t have tall buildings and why we have crazy rent control laws and strong renter’s rights.
Agree with that philosophy or not, it’s clear to all that the approach isn’t working, else we’d not be seeing pawns protesting against rooks sitting on white buses.
And in a final note, this Utah policy for fixing homelessness is amazing. The most interesting part to me is that
housing is not contingent on participation in supportive treatment programs or an expectation of abstention from drugs or alcohol, but on the basics of good tenancy. Residents are guaranteed stable housing as long they are good stewards of their personal and shared housing areas and maintain good relations with other tenants, case managers, and property managers.
Let’s get away from pointless moralizing and just focus on fixing the damn problems.