This feed omits posts by rms. Just 'cause.
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.
Because of recent news reports, I wanted to cross check the cost feasibility of the NSA's recording all of the US phonecalls and processing them.These estimates show only $27M in capital cost, and $2M in electricity and take less than 5,000 square feet of space to store and process all US phonecalls made in a year. The NSA seems to be spending $1.7 billion on a 100k square foot datacenter that could easily handle this and much much more. Therefore, money and technology would not hold back such a project -- it would be held back if someone did not have the opportunity or will.
Another study concluded about 4x my data estimates others have suggested the data could be compressed 10:1, and the power bill would be lower in Utah.
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!
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.
$ 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
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 ...
Plasma Desktop Scripting
// open the kickoffrc file
var config = ConfigFile('kickoffrc');
// switch to the RecentlyUsed group
config.group = 'RecentlyUsed';
// write an entry into it
config.writeEntry('MaxApplications', 25);
// now put Yes=20 into RecentlyUsed/Test
var config2 = ConfigFile(config, 'Test);
config2.writeEntry('Yes', 20);
QML
- A plasmoid (or other) package can provide fallbacks for SVGs that are themed. This allows a plasmoid to safely use an SVG that may only be in some themes while providing its own fallback. Taking this even further, you can even provide SVGs for specific themes by dropping them in a folder that shares the theme's name.
- A units object was introduced that provides compatibility with Ubuntu Touch's object of the same name. They work identically, and the idea is to make writing apps that target multiple platforms a bit easier. Scanning through various QML applications written with Ubuntu Touch in mind, this was by far and away the most often used bit of their API. Personally, I disagree with using such literal units and prefer to have fluid layouts, but compatibility is a boon for all QML platforms.