05 November 2015

There is no dark side of the moon really. Matter of fact it's all dark.

The moon's albedo is actually quite low. The Earth is significantly brighter, thanks to the clouds and oceans... which are shiny enough that there's a visible highlight in the center of the disc from the sun directly behind the spacecraft. So in this image, with the brightness adjusted for the larger planet, you get to see the true color of our dry, airless companion world.

Suggested listening for the day: Albedo 0.39

Aug 5: From a Million Miles Away, NASA Camera Shows Moon Crossing Face of Earth

02 October 2015

The Last Android Villain...

I bought a non-Nexus Android phone a few years back. It was my first smartphone. It was released less than a year before Android 4.0 shipped. When I bought it, ICS was already going out to developers.

Did it get an update?


The cellphone business is chronically sick.

In this article disparaging Nexus phones as "advertising" Vlad Savov writes:
Google's Nexus phones are just ads
I've spent the past couple of days desperately trying to puzzle out the purpose behind Google's newly announced Nexus 5X and 6P smartphones. [...]
One word. Updates.
Google, our knight in shining armor and a propeller hat, has come to save us from the evils of perfidious carriers, ugly Android skins, and late software updates.
I wouldn't mind late software updates. I mind not getting them at all. If you get a flagship phone, it might get updates for a year or two. Then I guess you're supposed to buy a new phone. If you get a mid-range or entry-level phone? You get Bollocks.
There isn't a single Android device manufacturer that is happy with the Nexus program, and I've spoken with them all.
Have you asked them about updates?
Motorola went all-out with the Moto X Pure this year, seeking to deliver the cleanest possible Android experience, best possible specs, and lowest possible price, all while operating independently of carrier interference.
Now they're no longer owned by Google, let's see how they do with updates. If they keep them up, I'll consider getting one. There's a lot of things I really dislike about Nexus phones. Like the lack of SD card slots, which more or less force you to depend on the Google cloud.
 Android phone makers have grown more conscientious and restrained.
Except when it comes to updates.
There is no Android villain left for the Nexus crusader to slay.
Making Android profitable for Android phone makers is one of the great challenges of our time.
I'd be happy with a spec-for-spec replacement for my Nexus 4, with an SD card slot. Is that hard to do? The Nexus 5X is more than I want. I was looking at Chinese phones shipping with plain old AOSP or Cyanogen, because I knew the community could support them even if the manufacturer couldn't.
I wish Google would recognize that and try to do more to support Android as a whole rather than just its own good name.
With the phone manufacturers undercutting it all the time, by releasing phones that never receive a single update, they kind of have to.

27 December 2014

The pre-history of sudo...

I was reminded by this article on Evi Nemeth of the days before sudo. It seems like every group of UNIX users had an "su alternative" that avoided having to share the root password.

The su alternative at Berkeley was called "setsh". It wasn't just used for root, users could let other users into their account using setsh - this was a necessary evil back then because users could only be in one group at a time. It was generally distributed as source, users would edit the names of other users they wanted to let into their account into a table in the code, and compile it and leave a copy in ~/bin. So to run a command as someone you were working with you'd run "~them/bin/setsh" and if you were in the list, you'd get a shell su-ed to them.

Surprisingly, in hindsight, I don't recall ever hearing of anyone putting a boobytrap into ~/bin/setsh.

10 December 2013

BCPL pointers were not zero indexed because of compile time issues.

Re: Citation Needed - blarg?

Mike has done a bit of research, but not enough. Reading and understanding the BCPL manual (let alone having any experience with '60s and '70s compiler technology) would have made this jump from Martin Richard's comment (which says nothing about the cost of optimizing the code) to "in that context none of the offset-calculations we’re supposedly economizing are calculated at execution time" obviously wrong.

First, the yacht thing is a complete red herring. You always had to limit your job run times because computers were just plain unreliable. They could easily go down several times a day, forcing the restart of a job. Higher priority jobs could always show up and bump you, and getting bumped was not all that big a deal... you'd just get run again once it was done, if by chance you happened to be late in the queue you'd run a day or so later at the most... and that could happen anyway if jobs before you ran into problems or there was too much maintenance downtime. A handicapping run a few times a year? that's nothing.

Second, you could have expressions on both sides of the dyadic "!" operator. "V!I" was exactly the same as "I!V" ... Richards spells that out explicitly in the text Mike quoted! There's no reason to treat it as a compile-time-only issue.

Third, of course BCPL had pointers. It was completely typeless, an address was just a number. When you wrote


You create both a pointer variable "V" and allocated a 5 element array to it. Yes, it really allocated a total of six cells. As far as I recall, "V" could be reassigned to point to another vector, or incremented within itself.

Fourth, local variables were dynamically created on the stack. So a local


could be at any address in the stack, depending on the call history.

Fifth, and backing up my recollection in the third point, the BCPL manual has an example of pointers being initialized on page 27:


Sixth, he's applying 21st century reasoning about compilers to the '60s. When you wrote:


it's virtually certain that the compiler would actually generate the code to fetch "V" and add one to it. I would be staggered to learn that the compiler optimized away this extra indirection, ever, because that would have required tracking the state of every variable used as an lvalue to know when that optimization was safe.

Finally, seventh, and most critically, using 1 index on the dyadic "!" operator would have caused extra complexity for *programmers*, because suddenly "!(V+I)" would mean something different from "V!I", and having "!(V+I)" mean "the memory at V + I + 1" would be just nutty.

BCPL arrays, like C arrays, were zero-origin because it fell naturally out of the unification of pointers and other values in a low level language.

13 August 2013

Hipster NSA

Hipster NSA was into data before they got big.
Hipster NSA only taps underground cables.
Hipster NSA says you don’t really collect data until you listen to it.
Hipster NSA stopped 50 terrorist attacks. You’ve probably never heard of them.
Hipster NSA stalked you before you were cool.

28 June 2013

Onward Sauron’s Soldiers

Just leaving this here...

Onward Sauron’s Soldiers

Words by Richard Tatge, Al Kuhfeld and Ken Fletcher. Sung to the tune of 'Onward Christian Soldiers'

Onward Sauron’s soldiers,
Marching as to war,
With the eye of Sauron
Going on before
Darkness like a banner
shadows all the foe.
Forward into battle see the Nazgul go.

Onward Sauron’s soldiers,
Matching as to war,
With the eye of Sauron
Going on before.

Trolls and Balrogs mangle
Dragons burn and bite!
With us you must tangle
Or run and scream in fright.
Evil is our watchword,
Pain is our delight;
Middle-Earth must crumble,
Under Mordor's might.


From the dread dark tower.
To the black Khazad-dum.
We’ll send elves and hobbits
Shrieking to their tomb.
Men and dwarves together
Go down in defeat.
In the hunger after the battle.
They’ll be nice to eat.


Conquer every village!
Yell out the battle cry!
Murder, rape and pillage,
Then spit in their eye!
See the craven victims
Quivering with fear:
We’ll be leaving Mordor
Sometime late next year.