07 February 2016

No, blowing up the Death Star won't collapse Galactic Civilization.


What part of "it's a galactic civilization" did you miss?

1. The Republic/Empire is a robust Kardashev level II civilization, and not a young one. It's got a LOT of civilized worlds, and is clearly heading for KIII classification. Blowing up a whole planet didn't kick off a depression. Analyzing the resources of a civilization like that using assumptions based on our civilization is like Pliny the Younger looking at the possibility of building an aircraft carrier based on the resources of a slave-based economy and deciding that sinking a single vessel would collapse the world's economy.

2. The Death Star is not productive infrastructure. It's sunk costs. Any economic impact it has is in the past. If maintaining the production lines for the Death Star have a positive impact on the economy, then blowing it up to keep the lines flowing as you build another one is probably the best thing you can do. Of course those same production lines can be used for building, I don't know, modern housing for Jakku scavengers instead. Point is, there's no benefit to the Galactic economy from the continued existence of the Death Star.

3. They make a big deal about the amount of steel involved. That amount of steel is basically lying around in nickel-iron asteroids for the taking in any "dirty" system with a lot of small body matter. That whole part of the paper is like Pliny calculating how many slaves would be needed to dig up the iron ore for the aircraft carrier I mentioned two paragraphs back.

30 December 2015

New Years Resolutions

A quick search on Google confirmed that people are really not stretching themselves when choosing their new years resolutions.

Search term "new years resolution" "1920x1280" got a creditable 33,000 hits... but it looks like almost 80,000 people were willing to put up with 640x480:


COUNT   RESOLUTION
67      2560x2048
239     1900x1200
878     1152x864
2330    1440x1080
4600    1280x1024
9130    2048x1536
10600   1280x960
33000   1920x1080
38400   1024x768
53400   800x600
78900   640x480


Shameful, really

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?

Bollocks.



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.
Updates.
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

LET V = VEC 5

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

LET V = VEC X

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:

LET IOV = VEC 650
LET IOVP, IOVT = IOV, IOV + 650

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

V!1

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.