Edward Snowden turns out to be just the hero for our age. Getting condemned as a traitor by former (and by the evidence, maybe permanent) Power Behind the Throne Dick Cheney is a real feather in his cap. I wish I could be condemned as a traitor by Dick Cheney. Imagine how great a country would be if if it were governed entirely by people who Dick Cheney would call Traitor.

What they are not telling us is that the reason they only need the "metadata" from the phone companies is not that they respect anyone's privacy. It's that they already have all the audio logged, going back years; but they need the metadata to know who's talking. They got tired of asking the phone companies for metadata on bits they had tagged as interesting, and just demanded the lot.

I bought a Sandisk "Extreme Pro" SDHC card, advertised as supporting "up to 90 MB/s" reads and writes, to use in my Wandboard. Copying a 2.5G image onto it, I got all of 11 MB/s. I guess they only guarantee that it won't go over 90 MB/s, and maybe blow out my SD socket. Thoughtful of them.

I've heard it said that you can just alternate between two UI themes once a week, and every time you switch, the new one will feel prettier, newer, and more exciting than the old one.

This is a natural tendency. The human mind is intrigued by change. That's where fashion comes from, and fads. It gives you a little burst of some chemical, maybe adrenaline (fear of the unknown?), or endorphins (appreciation of the unexpected?), or perhaps some other kind of juice I heard of somewhere but I don't really know what it does.

In tech, this kind of unlimited attraction to the unexpected is the main characteristic of the first phase of the Technology Adoption Lifecycle, the so-called "Innovators."

Perhaps people are happy to be included in the Innovator category. But Innovation isn't just doing something different for the sake of being different. Real innovation is the *willingness* to take the *risk* to do something different, because you know that difference is expensive, but that it will pay off in some way that more conservative sorts will fail to recognize until later.

In fashion, the end goal is to catch people's attention; if you do that, you are innovative. That's why fashion repeats itself every few years: because you can be innovative over and over again with the same ideas, rehashed forever.

In technology, we can hold you to a higher standard. Innovation requires difference, but it also requires a vision of usefulness. Change is expensive. Staying the same is cheap. Make it worth my while. Or if I'm an Innovator, or even an Early Adopter, at least give me a hint about how it's worth my while so I can exploit it while others are too afraid.

Every needless change creates expensive fragmentation. Microsoft ruled their market by being change averse. So did IBM. So did Intel. Even Apple. Whenever they forgot this, they stumbled.

Change aversion works because what makes a platform successful isn't so much the platform as the complementary products. For a phone, that means third-party power adapters, car chargers, headphones with integrated volume controls, alarm clocks with a connector to charge your phone *and* play your music at the same time. For a PC, it could be something as simple as maintaining the same power supply connector across many years' worth of models, so that anyone who standardizes on your brand will have an ever-growing investment in leftover power supplies plugged in wherever they might want them. For an operating system, it means keeping the same approximate style of UI for a long time, so that apps can learn to optimize for it, and a really great app made two years ago can keep on selling well, perhaps with bugfixes and new features but no need for rewrites, because it still looks like it's perfectly integrated into your OS experience. That sort of consistency allows developers to focus on quality instead of flavour, and produces an overall feeling of well-integratedness. It makes people feel like when they buy your thing, they're paying for quality. And yes, people - moving beyond the innovators into the more profitable market segments of the curve - will definitely pay for quality.

Real design genius lies in the ability to make something look pretty, and with gentle updates to keep it modern looking, without causing huge disruption to your whole ecosystem every couple of years. Following fashion trends, while not caring about disruption, does not require genius at all. All it requires is a factory in a third-world country and some photos of what you want to copy.

Ironically, even app developers mostly fail to recognize just how bad it is for them when a platform changes out from under them unnecessarily. Instead, they get excited by it. Finally, I get to rewrite that UI code I really hated, and while I'm there, I can fix all those interaction bugs I knew we had but could never justify repairing! Because now I *have* to rewrite it!

Redesigning things to match a moving target of a platform is really comforting, because it's a ready-made strategy for your company. The truth is, you don't have to think about what customers want, or how to make the workflow smoother, or how to eliminate one more click from that common operation, or how to fix that really annoying network bug that only happens 1 in 1000 times. Those bugs are hard; this feels like freedom. We'll just dedicate our team to "refreshing" the UI, again, for another few months, and nobody can complain because it's obviously necessary. And it is, obviously, necessary. Because your platform has screwed you. Your platform changed for no reason, and that's why your users can't have what they really need. They'll get a UI refresh instead.

And although they are less productive, they will love it. Because of endorphins, or sodium, or whatever.

And so you will feel good about yourself in the morning.

For almost all of my life, I have hated rice pudding. But recently my wife made some (up to now, I’ve only seen her eat it from a tin – disgusting stuff). And it was awesome. So now I keep making rice pudding.

I recently had occasion to cook it for a lot of people. Here’s the recipe.

500g pudding rice
250g demarara sugar
1l whole milk
flavourings (see below)
ground nutmeg

Flavourings: there’s probably a lot you can do, but the two I did most recently were (choose one):

a) Zest of two oranges (I like to peel them with a potato peeler and then finely slice the peel) plus ground seeds from about 20-30 cardamom pods (pods removed).

b) Zest of two limes and two lemons (as above).

Put nearly all ingredients in a flat oven dish, should be about 1.5″ deep and mix. Dust the top with nutmeg. Cook at gas mark 3 for 2 hours.

This should give you a nearly completely dried out rice pudding, with just a touch of moistness and a strong flavour. Which is how I like it.

Serve with double cream. Should feed 12 generously.

What? I didn’t say it was slimming!

Share This

The first maintenance release 1.8.3.1 is out.

This is primarily to push out fixes to two regressions that seems to have affected many people recently.  Sorry about that.

• With Git 1.8.3, an entry "!dir" in .gitignore to say "This directory's contents is not ignored, unless other more specific entries tells us otherwise" did not work correctly. This regression has been fixed.
• With recent Git since 1.7.12.1 or so, "git daemon", when started by the root user and then switched to an unprivileged user, refused to run when ~root/.gitconfig (and XDG equivalent configuration files under ~root/.config/) cannot be read by the unprivileged user. The right way to start the daemon might be to reset its $HOME (where these configuration files are read from) to somewhere the user the daemon runs as, but it is cumbersome to set up. With 1.8.3.1, failure to access these files with EPERM is treated as if these files do not exist, which is not an error.

The git branch Porcelain command, when run without any argument, lists the local branches, and shows the current branch prefixed with an asterisk, like this:

$ git branch
* master
  next
$ git checkout master^0
$ git branch
* (no branch)
  master
  next

The second one with (no branch) is shown when you are not on any branch at all. It often is used when you are sightseeing the tree of a tagged version, e.g. after running git checkout v1.8.3 or something like that.

To find out what the current branch is, casual/careless users may have scripted around git branch, which is wrong. We actively discourage against use of any Porcelain command, including git branch, in scripts, because the output from the command is subject to change to help human consumption use case.

And in fact, since release 1.8.3, the output when you are not on any branch, has become something like this:
$ git checkout v1.8.3
$ git branch
* (detached from v1.8.3)
  master
  next

in order to give you (as a human consumer) a better information. If your script depended on the exact phrasing from git branch, e.g.

branch=$(git branch | sed -ne 's/^\* \(.*\/\1/p')
case "$branch" in
'('?*')') echo not on any branch ;;
*) echo on branch $branch ;;
esac

your script will break.

The right way to programatically find the name of the current branch, if any, is not to use the Porcelain command git branch that is meant for the human consumption, but to use a plumbing command git symbolic-ref instead:

if branch=$(git symbolic-ref --short -q HEAD)
then
  echo on branch $branch
else
  echo not on any branch
fi

You might not realize it, but there's an imminent phone number shortage. It's been building up for a while, but the problem has been mitigated by people using "PBXes", which basically add a 4-5 digit extension to the end of your phone number to expand the available range. The problem with PBXes is they don't work right with caller id (it makes it look like a bunch of people near each other all have the same phone number) and you can't easily direct-dial PBX extensions from a phone's integrated address book, unless your phone has some kind of special "PBX penetration" technology. (PBX penetration is pretty well-understood, but not implemented widely.)

Even worse: it's no longer possible to route phone calls hierarchically by the first few digits. Nowadays any 10-digit U.S. phone number could be registered anywhere in the U.S. and area codes change all the time.

So here's my proposal. Let's fix this once and for all! We'll double the number of digits in a Canada/U.S. phone number from 10 to 20. No, wait, that might not be enough to do fully hierarchy-based call routing, let's make it 40 digits. But that could be too much typing, so instead of using decimal, we can add a few digits to your phone dialpad and let you use hexadecimal instead. Then it should only be 33 digits or so, with the same numbering capacity as 40 decimal digits! Awesome!

It'll still be kind of a pain to remember numbers that long, but don't worry about it, nobody actually dials directly by number anymore. We have phone directories for that. And modern smartphones can just autodial from hyperlinks on the web or in email. Or you can send vcards around with NFC or infrared or QR codes or something. Okay, those technologies aren't really perfect and there are a few remaining situations where people actually rely on the ability to remember and dial phone numbers by hand, but it really shouldn't be a problem most of the time and I'm sure phone directory technology will mature, because after all, it has to for my scheme to work.

Now, as to deployment. For a while, we're going to need to run two parallel phone networks, because old phones won't be able to support the new numbering scheme, and vice versa. There's an awful lot of phone software out there hardcoded to assume its local phone number will be a small number of digits that are decimal and not hex. Plus caller ID displays have a limited number of physical digits they can show. So at first, every new phone will be assigned both a short old-style phone number and a longer new-style phone number. Eventually all the old phones will be shut down and we can switch entirely to the new system. Until then, we'll have to maintain the old-style phone number compatibility on all devices because obviously a phone network doesn't make any sense if everybody can't dial everybody else.

Actually you only need to keep an old-style number if you want to receive *incoming* calls. As you know, not everybody really needs this, so it shouldn't be a big barrier to adoption. (Of course, now that I think of it, if that's true, maybe we can conserve numbers in the existing system by just not assigning a distinct number to phones that don't care to receive calls. And maybe charge extra if you want to be assigned a number. As a bonus, people without a routable phone number won't ever have to receive annoying unsolicited sales calls!)

For outgoing calls, we can have a "carrier-grade PBX" sort of system that basically maps from one numbering scheme to the other. Basically we'll reserve a special prefix in the new-style number space that you'd dial when you want to connect to an old-style phone. And then your new phone won't need to support the old system, even if not everyone has transitioned yet! I mean, unless you want to receive incoming calls.

...

Or, you know. We could just automate connecting through a PBX.

Two weeks ago I attended GNOME.Asia/Seoul and LinuxCon Japan/Tokyo, thanks to sponsoring by the GNOME Foundation and the Linux Foundation. At GNOME.Asia I spoke about Sandboxed Applications for GNOME, and at LinuxCon Japan about the first three years of systemd. (I think at least the latter one was videotaped, and recordings might show up on the net eventually). I like to believe both talks went pretty well, and helped getting the message across to community what we are working on and what the roadmap for us is, and what we expect from the various projects, and especially GNOME. However, for me personally the hallway track was the most interesting part. The personal Q&A regarding our work on kdbus, cgroups, systemd and related projects where highly interesting. In fact, at both conferences we had something like impromptu hackfests on the topics of kdbus and cgroups, with some conferences attendees. I also enjoyed the opportunity to be on Karen's upcoming GNOME podcast, recorded in a session at Gyeongbokgung Palace in Seoul (what better place could there be for a podcast recording?).

I'd like to thank the GNOME and Linux foundations for sponsoring my attendance to these conferences. I'd especially like to thank the organizers of GNOME.Asia for their perfectly organized conference!

Hugh Daniel, a very well known hacker and cypherpunk, was found dead in his apartment a few days ago. Hugh was a terrific guy and a friend of all the world, the kind of cheerfully-larger-than-life personality that makes things a little merrier and more interesting wherever it goes. He’s going to leave a big Hugh-shaped hole in a lot of lives, including mine.

But I had a presentiment when I heard the first report of Hugh’s death, which was borne out when the first information came out about probable cause. Friends report that the coroner is fingering stroke or heart disease – but I’ve seen this movie before.

Because I’ve seen this movie before, I make a prediction. If they autopsy Hugh, they will find evidence of undiagnosed type II diabetes, non-alcoholic cirrhosis of the liver, serious coronary plaque, and probably marginal function in the kidneys and other organs. He will present similarly to a victim of long-term, low-grade poisoning.

About three years ago, another friend of mine, a gamer named Richard Butler, died with these symptoms. The two were about the same age when they died; both physically large men with big booming voices, happily extroverted geeks with a knack for making friends wherever they went, and the kind of zest for life that can make someone seem unkillable.

And both looked prematurely aged in photographs I saw shortly before their deaths. The energy was still there, but in retrospect the body was beginning to fail.

I think I know what actually killed Hugh and Richard. I don’t think it was old age in the normal sense; neither of them was even 60, if I’m any judge. I’m sounding an alarm because I think a significant number of my peers could die the same, preventable death.

The medical establishment calls it “metabolic syndrome”. Or, sometimes, “cardiometabolic syndrome”, “insulin-resistance syndrome”, “Reuven’s syndrome” or “syndrome X”. It’s associated with hypertension, cardiac disease, obesity, and diabetes.

A significant thing about Richard and Hugh is that they were both large-framed men who carried, rather gracefully, an amount of overweight that would have looked morbid on a smaller physique.

Most doctors would observe this, shrug and say that the overweight is what killed them. And, as far as that goes, it’s probably not wrong. But I have come to believe that the actual underlying cause of such overweight and metabolic syndrome is fructose poisoning.

When I first heard that Richard had fatty cirrhotic deposits in his liver when he died, I didn’t know what that meant. A few months later I learned that this is what happens when the liver becomes overloaded with hepatotoxic compounds and secretes encapsulating fat to defend itself. Alcohol stimulates this response; so does the fructose component in sugar. If an autopsy opens Hugh’s liver, that’s what I’d bet they’ll find signs of.

The hepatic poisoning deranges half a dozen critical metabolic pathways. The secondary effects of the derangement are the whole range of metabolic-syndrome symptoms, including cardiac disease and diabetes and probably stroke as well.

People look at this and think “It’s just old age.” It isn’t. It’s almost certainly fructose poisoning. I think I’ve just lost my second friend to it. I don’t want to lose a third.

If you’re reading this, and you’re overweight, please cut the goddamn fructose out of your diet before it kills you. No more HFCS-laden sodas. No more white-sugar-from-hell desserts. You even need to back off the fruit juices; I used to drink a lot of apple juice, but don’t any more.

Watch the ingredients lists on what you eat. The liver’s ability to process fructose non-toxically is limited; nobody’s sure what the limit is and it probably varies, but most people who have looked into this think about 50g of fructose per day is the most you should risk. Sucrose (cane sugar) is 50% fructose; convert accordingly.

Becoming a no-sugar fanatic isn’t required. Whole fruit is reasonably safe because the fiber slows the fructose uptake, making it unlikely that you’ll hit your liver’s conversion limit. I have a cup of cocoa most nights, about 16g of fructose. Occasionally I treat myself to cheesecake or even baklava. The point isn’t ritual self-denial, it’s to not go over 50g a day.

Please do these things to live. And to not be fat as a whale. It’s not complicated or difficult, it just takes a little attention. And I’m tired of watching friends die needlessly.

UPDATE: I misremembered. Richard Butler wasn’t found dead, he died in a hospital.

It's that time again: Luminosity! In episode 14 I'll be visiting the following topics as well as taking your questions as we go:

• Grass roots Free software promotion: A lot of the effort of introducing and generally marketing Free software to the public lands on the shoulders of companies these days. They tend to be able to grab a larger audience than the average individual and they can keep pounding out a message for an extended period of time. Yet .. Free software as a concept and many of the best Free software products are not very well known. Is there an opportunity for effective grass roots promotion?
• Wesnoth: Looking at my list of possible topics, I realized that I had been covering a fair number of serious topics and very few frivolous and fun ones. So why not .. let's have some fun this week and take a look at Wesnoth, what makes it tick and keeps people not just playing it but still developing it after all these years. We'll try not to get sidetracked into an actual game as we look at this venerable Free software game.
• Q&A: If you have a burning question to ask, do so in the comments here or on G+ and I'll do my best to get to it in the show. Or you can ask live on irc ...

Since Martin blogged about the new scripting related features in kwin coming to 4.11 today, I figured that I would do the same for plasma-desktop.

Plasma Desktop Scripting

QML

It is my pleasure to attend the HITCON 2013 and COSCUP 2013 conferences in July/August this year. They are both in Taipei. HITCON is a hacker/security event, while COSCUP is a pure Free/Open Source Software conference.

At both events I will be speaking at the growing list of GSM related tools that are available these days, like OpenBSC, OsmcoomBB, SIMtrace, OsmoSGSN, OsmoBTS, OsmoSDR, etc. As they are both FOSS projects and useful in a security context, this fits well within the scope of both events.

Given that I'm going to be back to Taiwan, I'm looking very much forward to meeting old friends and former colleagues from my Openmoko days in Taipei. God, do I miss those days. While terribly stressful, they still are the most exciting days of my career so far.

And yes, I'm also going to use the opportunity for a continuation of my motorbike riding in this beautiful country.

I've been watching a great set of threads roll by in my email related to a re-boot to the human interface guidelines used by the KDE community. The blog posts by Thomas and Björn explaining what they are up to are great reading and it gives those of us who are developers a really good reminder about user interface fit and finish. ( .. and therefore the above ironic memegif

Inspired, I spent a bit of time in the wallpaper setting dialog yesterday working on visual consistency and typography issues. The fixes were all little things that are pretty unsexy and would not make for an interesting blog if weren't for this new HIG work. It is these "little" things, however, that make things feel not just more polished but more trustworthy and desirable to use. It creates a comfort that people respond to on an emotional level. They find themselves moving through their tasks with more ease and less distraction; the human mind is very good at ignoring sameness and by contrast picking out differences.

So this is a little note of encouragement to my fellow developers for us to pay attention to the human interface guidelines as they take further shape and to redouble our effort to polish the GUI.

Note that we've been working on a HIG that is relevant for touch, also led by Thomas, and as that has been taking more and more shape it will become an important resource for those building applications with QML for devices who wish their interfaces to rock. Just as we have managed to keep a unity on the desktop between the user interfaces, we can do the same on mobile.

Today, very sad news has reached me: Atul Chitnis has passed away. Most people outside of India will most likely not recognize the name: He has been instrumental in pioneering the BBS community in India, and the founder and leader of the Linux Bangalore and later FOSS.in conferences, held annually in Bangalore.

I myself first met Atul about ten years ago, and had the honor of being invited to speak at many of the conferences he was involved in. Besides that professional connection, we became friends. The warmth and affection with which I was accepted by him and his family during my many trips to Bangalore is without comparison. I was treated and accepted like a family member, despite just being this random free software hacker from Germany who is always way too busy to return the amount of kindness.

Despite the 17 year age difference, there was a connection between the two of us. Not just the mutual respect for each others' work, but something else. It might have been partially due to his German roots. It might have been the similarities in our journey through technology. We both started out in the BBS community with analog modems, we both started to write DOS software in the past, before turning to Linux. We both became heavily involved in mobile technology around the same time: He during his work at Geodesic, I working for Openmoko. Only in recent years his indulgence in Apple products was slightly irritating

Only five weeks ago I had visited Atul. Given the state of his health, it was clear that this might very well be the last time that we meet each other. I'm sad that this now actually turned out to become the thruth. It would have been great to meet again at the end of the year (the typical FOSS.in schedule).

My heartfelt condolences to his family. Particularly to his wonderful wife Shubha, his daughther Anjali, his mother and brother. [who I'm only not calling by their name in this post as they deserve some privacy and their Identities is not listed on Atuls wikipedia page].

Atul was 51 years old. Way too young to die. Yet, he has managed to created a legacy that will extend long beyond his life. He profoundly influenced generations of technology enthusiasts in India and beyond.

• CIOL: Open Soruce guru Atul Chitnis, 51, no more
• NDTV Gadgets: Shine on, You Crazy Diamond: Atul Chitnis (1962-2013)
• lwn.net notice
• dna India: Atul Chitnis's death moves people
• Firstpost: Indian tech world mounrs death of open source guru Atul Chitnis
• NextBigWhat: R.I.P Atul Chntins: The Man Who Changed the Open Source World
• NetworkWorld: Open source luminary Atul Chitnis dies of cancer at age 51
• Farewell Atuli Chitnis - He taught India how to use a modem
• Remembering Atul Chitnis
• Goodbye my friend
• Tarique Sani: Live forever Atul!
• yurstory.in: A fw of the many ways in which Atul chitnis touched our lives...
• NextBigWhat: Atul Chitnis, Ahead of His Time Once More
• Financial Express: Freedom fighter Atul Chitnis drove the free and open source software movement
• Atul Chitnis, chapion of open source tech, dies
• Business Standard:Atul Chitnis: THe gurus' guru
• newskarnataka.com: Tech guru and open source software advocate Atul Chitnis is no more
• The Startup Guy: Goodbye Atul Chitnis
• All about Belgaum: Atul Chitnis is no more
• slashdot.org: Indian FOSS Evangelist Atul Chitnis Dead At 51
• vgrass.de: Atul Chitnis, RIP
• My Brother Atul Chitnis (1962-2013)

During development of Plasma Active, I resurrected an idea that a couple of us had tinkered with a year or two earlier: creating an open content store. We have ended up creating something fairly different than what is available out there right now and none of these differences are accidental. Before launching into a description of what this system is and how it works, I thought I'd start with a short blog entry describing the things we were not happy with in the state of the art of app stores. Later in the week I'll follow up with a description of our solution. For now, here is a little list of disappointments:

• Proprietary implementations. For some reason there haven't been significant Free software offerings in this area, even in Free software contexts!
• Centralized control. Trusting your content delivery to a gatekeeper entity's whims is madness.
• It's a store. Emphasis on "a": one front end, one catalog of content.
• App stores are .. well .. app stores. Music and books and art and other things are usually presented separately. 
• Feedback mechanisms are quite obviously afterthoughts. No one makes money off of those star ratings and commens, so why bother?
• Single economic theory. There is a single economic theory that drives all these stores. Want to have a store for a school system that uses a different economic model? Good luck.
• Limited opportunity for tie-ins with Free culture (including free software) and independent production houses.

Here's a very quick and terse update on where we are with hardware for the long-awaited (by me if noone else Vivaldi tablet hardware:

• SoC PCBs: done
• Mer: booting
• Plasma Active: starts
• X11: running, still toying with opengl
• Still waiting on a pair of drivers
• Casework being tweaked to smooth out some rough edges
• Screen components: sourced and ready

Which means we are finally, after months of unexpected delays (it's amazing how many different ways a PCB can be done in not-quite-the-right way ...) we have production designs in the box. We're not quite at the point where we can send them shuffling off the production line into little boxes to send to you, but we actually have a device that works and whose design we own so that our ability to deliver is in our own hands.

During this time we've moved our focus from the single core SoC to a pin-compatible dual core version to keep up with the times a bit as well as brought a better screen into the mix. I would like to post official specs but I don't want to tempt fate into changing anything on us as a result. See how projects like this can turn an otherwise secular minded person superstitious?

We will be rolling out the new website, specs, ordering and unveiling content store opportunities nearly simultaneously. The path to an open device has been insanely long. We aren't doing this on our own, however. We are working with a number of companies in Europe and a handful of companies in Asia on the engineering and production sides. In the process, we've ended developing what is a pretty snazzy little hardware tinkerer's device as well which we plan to make available separately from the tablet devices for those of you who like playing with such things. Below is a video showing one of these devices in action:

Lately I've noticed a number of new themes popping up for Plasma Desktop, which is quite cool. Things like this mash-up by Pawan Yadav:

and this Google inspired one by Half-left:


Combined with things like the Plasma Panels Collection it is pretty impressive what one can achieve. Moving into the Plasma Workspaces 2 era, this is only going to get more interesting as we introduce the Look and Feel packages that compliment the icon and SVG themes and bring the various user experiences (desktop, netbook, tablet, etc.) closer together for fast UX switching.

One thing I keep dreaming about is a group of artists who enjoy this kind of work and have experience bending Plasma to their will coming together to create some ellegant and distinctive artwork and then pitch that work to the wider KDE art community. No asking of permission involved, just come up with a refined and audacious proposal for the desktop theme. In the worst case scenario we'd have something great for users of Plasma workspaces to optionally select .. and in the best case scenario we might find consensus on a new visual twist for Plasma Workspaces 2.

Until then, I'm enjoying the swell of art and presentation that can be used right now with Plasma Desktop.

I just bought a used Pantech Burst (also called Presto, and P9070) Android phone for US$50, from craigslist. It has a dual-processor Snapdragon ARM7, 1GB RAM, 16GB flash, and a microSD slot. It was running ICS until I replaced that with (Slim's unofficial port of) Cyanogenmod 10. These can be had easily for well under US$100 on ebay, making it the best value I know of in a smartphone. The batteries are supposed to run out a little faster than some other phones, but you can get a pile of spares, and a busted phone to charge them with, very cheap.

I also bought a Wandboard, a 4.5-inch-square complete computer system with dual ARM, 1G RAM, USB (both host and gadget), GigE, 2 microSD slots, SATA, WiFi, Bluetooth, optical and analog audio, HDMI, camera connector, serial, JTAG, and an expansion header, that burns <2W, for $100. A handsome case is another $10. They provide Android Jelly Bean and Ubuntu boot images. This seems like a better value than a RasPi, Mele, or Beagle. Since I bought it they have added a quad CPU version with 2GB RAM for $20 more.

I bought a used Netgear WNDR3700 wifi router for $40. It had the buggy 1.0.0.32 firmware that refuses to load the (less buggy) 1.0.0.36 update. There are lots of these out there because they all automatically downloaded and flashed the bad firmware. I used tftp to downgrade it to 1.0.0.12 (got directly from Netgear), and then installed DD-WRT on it. It has plenty of flash and RAM, and a USB socket.

I also bought a used Cisco/Linksys EA2700 wifi router, also for $40. These are cheap now despite excellent features (agbn, 64M RAM, 64M flash) because the Cisco firmware in them has turned out to be easy to crack remotely, but now it can run DD-WRT.

The 1.8.3 release has finally been tagged and pushed out to the usual places. Also the release tarballs at kernel.org are back.

For a list of highlights, please see the previous post on -rc2; not much has changed since then.
During the last development cycle including its pre-release feature freeze, a few more interesting topics were discussed, and at this moment there aren't actual patches or design work.

[Previous list of "leftover bits" is here]

• "git config", when removing the last variable in a section, leaves an empty section header behind. Anybody who wants to improve this needs to consider ramifications of leaving or removing comments.
  Cf. $gmane/219524
• Add "git pull --merge" option to explicitly override configured pull.rebase=true. Make "git pull" that does not say how to integrate fail when the result does not fast-forward, and advise the user to say --merge/--rebase explicitly or configure pull.rebase=[true|false]. An unconfigured pull.rebase and pull.rebase that is explicitly set to false would mean different things (the former will trigger the "fast-forward or die" check, the latter does the "pull = fetch + merge".
  Cf. $gmane/225328

Lucky number 13? Maybe! Tomorrow "Luminosity" will get its thirteenth installment.

• Why we work together, and why we sometimes don't: In Free software, forking used to be seen as a really bad thing reserved for unfixable situations. These days it happens all the time. Duplication of  effort was usually met with "Why?" rather than "Why not?", and typically reserved for the "beginner's application topic" (Was text editors, then irc (or mud!) clients, then media players, ..) Have we forgotten culturally the benefits of working together? Have new priorities shifted the playing field? When does it make sense to I'll try to make the case for less diversity than we have now, or at least a more responsible investment of effort.
• Open Build Service: We'll be looking at one of the coolest tools out there for people building software, images and operating system distributions: Open Build Service. We'll look at how it works, how it can be extended and at some self-hosting options.
• Q&A: If you have a burning question to ask, do so in the comments here or on G+ and I'll do my best to get to it in the show. Or you can ask live on irc ...

We are nearing the soft feature freeze for the 4.11 release, and that seemed like a good time to share some news. Plasma Workspaces 4.11 is going to significant for two reasons:

1. It will be the last feature release in the 4.x series of Plasma Workspaces. Feature development will switch fully to the Qt5 and KDE Frameworks 5 based Plasma Workspaces 2.
2. We will be providing stabilization releases (bug fixes, translation improvements, etc.) for two years for the 4.11 release of KDE Plasma Workspaces.

Before going into more details, let me offer a preemptive clarification:

This does not effect, in any way, anything other than the code currently in the kde-workspace repository. Applications are not affected, kdelibs and kderuntime will continue on as they currently are (with kdelibs in a feature freeze of its own already). I fully expect there to be a 4.12 and likely a 4.13 release of the applications, and how long that goes on will be up to the application developers and release team.

With that out of the way, some details!

Long Term Release

Decoupling the Software Compilation (Somewhat)

Shortening the Wait for Plasma Workspaces 2

How We Arrived At This Decision