Making it stick.

From The Register...

"Researchers from Radboud University in Nijmegen revealed two weeks
ago they had cracked and cloned London's Oyster travelcard and the
Dutch public transportation travelcard, which is based on the same
RFID chip. Attackers can scan a card reading unit, collect the
cryptographic key that protects security and upload it to a laptop.
Details are then transferred to a blank card, which can be used for
free travel.

Around one billion of these cards have been sold worldwide. The card
is also widely used to gain access to government departments, schools
and hospitals around Britain."

http://www.theregister.co.uk/2008/07/18/university_can_publish_oyster_research/

Here's just one reason why OSCON is in Portland each July...

http://www.wunderground.com/US/OR/Portland.html

You're welcome to your ideas. Your welcome to express them in writing, orally, and via many means at your disposal.

But you're not welcome to shout them at the top of your lungs in an otherwise peacefully quiet town square. That's disturbing the peace. You've disturbed mine twice recently.

It's not like I haven't encountered the same message hundreds of times a year, nearly each year of my life. I wonder what's at stake for you to feel compelled to choose this means?

I appreciate you are passionate about your ideas. Maybe you would respect a similar passion for my ideas. I cannot presume it is my place to express that passion so intrusively, no matter what my ideas, no matter how passionate I may be.

And believe me: I am a Smug Lisp Weenie. I can be passionate.

From The Register...

"Unless just about every technology company going has an "iPod
moment," then we're looking at a grim scenario where layoff reports
will become rather common. That's especially painful news for people
already being worked over by rising gas prices and painful mortgages.

We'll know just how bad these are for the technology sector, starting
today when Intel reports second quarter financial figures. Intel's
report will kick off three weeks of earnings reports - a journey
that's starting to look like a dive into the heart of darkness...

Worst of all, people are starting to try and understand Google's
business. Just wait and see what happens when Google really misses a
quarter, and everyone figures out that they have no idea how Google's
money machine works. That'll go over well."

http://www.theregister.co.uk/2008/07/15/tech_economy_woe/

"Nintendo this morning announced plans for a version of the
blockbuster "Grand Theft Auto" game franchise for the Nintendo DS
handheld game system. The hard-core game is atypical for a system that
has been built on more casual titles as "Nintendogs" and "Brain Age."
Dubbed "Grand Theft Auto: Chinatown Wars," the game will be available
this winter, the company says."

http://blog.seattlepi.nwsource.com/microsoft/archives/143556.asp?source=rss

I hope the choice is not "protocol buffers" or "xml".

Most people probably do not need anachronistic protocols or even
binary data formats over the wire.

On the other hand, few of us need XML either.

Not sure what an "expected" surprise means, but cool...

"Nintendo this morning gave a sneak preview of one the announcements
it's expected to make at its briefing here Tuesday: The company says
the new accessory, called the Wii MotionPlus, attaches to the Wiimote,
"more quickly and accurately reflecting motions in a 3-D space."
Here's the news release. No word on pricing or availability. The
company is promising more details at its briefing."

http://blog.seattlepi.nwsource.com/microsoft/archives/143393.asp?source=rss

The game industry focused on graphics the way Intel focused on
instruction speed. Nintendo snuck up on the industry with controllers
as the significant innovation the way AMD snuck up on Intel with lower
power and multiple cores a few years ago.

Joe Gregorio wonders about hardware support for functional languages...

I've been thinking about this in the context of the Professionalization of Scripting Languages, does anyone know if any of the processor manufacturers are working on adding silicon support for activation records?

I know first-hand Intel has been searching for ways to spend transistors for at least a decade. There's been some looking at objects including closures, generally, and some consideration of Smalltalk, Lisp, etc. But I am not aware of specifically looking at stack vs. heap allocation of activation records.

On the other hand I have witnessed decades of considerations of hardware support for functional languages. In each case the problems seem to have been solved at least as well with general-purpose hardware combined with clever software at compile-time and run-time. Looking back at the history of hardware support for Lisp and Smalltalk, and OOP and functional programming generally, will turn up many research and production efforts that have not panned out in the long-run. However the economics may have changed assuming scripting languages will become as "professional" (!) as Joe predicts.

I've been paid well from time-to-time over 25 years to program with sophisticated dynamic languages. That today we're just now thought to be entering a "professional" stage is an indicator that the profession is missing some of it's own literature. So please consider the following. From my historical viewpoint as a veteran dynamic language applications programmer, and dynamic language implementation aficionado, I believe activation record solutions you seek have a rich history of solutions to continue from (so to speak), and they are almost all in software.

Scripting languages are direct descendants of what I would consider long-time "professional" languages such as Smalltalk, Common Lisp, and Scheme. Until recently I suppose there's been little motivation for Ruby/Python/Javascript language implementers to dive into the literature of _implementing_ their predecessors. I would recommend anyone serious about it to begin with "the original lambda papers". Not that these were the first on efficient dynamic languages, but they start from first principles and are easy to read.

From there I would recommend moving on to work published by Appel, et al. for Standard ML/New Jersey (SML/NJ). A starting point is the text book "Modern Compiler Implementation". But this should also include all the research done around compiling ML.

Along the same lines are all the years of work around compilers and run-times for Scheme. SML/NJ and Scheme have particularly interesting activation/closure needs because they are mostly functional, but do have side-effects, and they also have first-class continuations. Look up various work by Kranz, et al. at Yale (in particular for the Orbit compiler for "T", a dialect of Scheme); Dybvig, et al. at Indiana U.; Feeley at U. Montreal; and Clinger, et al. at U. Oregon and Northeastern.

And then include the publications about Smalltalk, Self, etc. implementations by Peter Deutsch, David Unger, Craig Chambers (U. of Washington), and Eliot Miranda among others. Generally reading through the years of OOPSLA proceedings, especially the earlier years, and the proceedings of the ACM Lisp and Functional Programing Conference will keep you busy for a while.

Efficient implementation of first-class activation records revolves around a few decisions. One is whether or not to use the hardware stack at all. Some efficient implementations use the stack and copy to/from the heap as needed. Others use the heap solely. Efficiency also becomes intertwined with interoperability with "C" and so-called "native code".

These choices have more to do with first-class continuations and languages like Smalltalk that promote activation records as first-class objects. If you go back and look at MIT Scheme and work by Guillermo Rozas, they paid a lot of attention to providing features like continuations and first-class top-level environments without _always_ paying the price.

The more common problem of allocating heap for first-class lexical environments is probably even less conducive to hardware-based solutions. A naive compiler (the most naive compiler is a simple interpreter) will allocate a lot of heap and generate a lot of garbage. So part of the solution is how efficiently short-lived heap allocations can be collected. The more complicated compiler problem is analyzing the code to determine how to reduce the amount or frequency of allocated heap. Based on determining which closures are "upward", what lexical state must be captured, and which closures share some or all of that lexical state, a compiler can very smartly move state capture up or down the lexical scope.

For example if closure C1 captures variables V1, V2, and V3, and in the same scope closure C2 captures just V2, then C1 and C2 need to refer to the same "instance" of V2. But maybe V2 is bound several scopes "up" from V1 and V3. The compiler may choose to heap allocate space for V1, V2, and V3 at the point where V2 becomes bound. The C2's code is generated to reference V2 at some offset from the start of this allocation. C1 references all three slots.

And that's the simplest case I could write about. There are other problems that I've not thought about for at least 15 years. My main point is that none of this "professionalism" is new. Many problems new implementers will encounter have a long history of solutions that are likely to be sufficient and, minimally, good starting points. All of the software solutions could show up within a year, where hardware solutions would not show up for five if ever.

The hardware instructions for all of this are fairly basic: incrementing pointers, relative addressing, short jumps. Not much more than that. The problem is how to do as little of all that as possible by walking a lot of tree stuff at compile-time, and leaving a marker here or there at run-time.

In addition to diving into the literature, I would recommend studying, if not using directly as a "common language compiler and run-time" the Gambit Scheme compiler and run-time. Gambit is the system to beat for efficiency, if it is not going to be your system to utilize as a "back-end".

...but the cost of nothing.

Apologies to Alan J. Perlis. May he rest in peace.

http://www.cs.yale.edu/quotes.html

The CSI folks got a write up in Time along with a Beatlesesque photo. I knew them when.

In a recent comment here Dan Creswell refers to an algorithm for taking a global snapshot across a distributed message system...

...if our snapshot could just capture the "after" state, then we'd be done. However, we can't do that either because we're not allowed to stop the other messages flowing through the system after we take the local snapshot at a node. Therefore, by the time all nodes take their local snapshots, the global system state may have changed.

So, we define a recent and consistent global state as a global state that "could have occurred" between the "before" state and the "after" state. In other words, consider the sequence S of communication events that occurs in the system between the "before" and the "after" state. A recent and consistent global state X is reachable from the "before" state by some subsequence of the events in C. Furthermore, the "after" state is reachable from the state X by the remaining events in C. Notice that this global state didn't necessarily occur at any point in real time, but it "could have occured" between the "before" and "after" states using the same sequence of communication events.

Global snapshots are useful in a wide variety of distributed applications. One application is in distributed databases, for instance a group of bank branches. Another use is deadlock detection: a global snapshot can be examined to see if there has been any progress made by the algorithm. Termination of a distributed algorithm can detected in the same way.

From an interesting-looking course in distributed systems at Washington University, St. Louis.

From the EFF deeplinks blog...

Yesterday, in the Viacom v. Google litigation, the federal court for the Southern District of New York ordered Google to produce to Viacom (over Google's objections):

all data from the Logging database concerning each time a YouTube video has been viewed on the YouTube website or through embedding on a third-party website...

for each instance a video is watched, the unique “login ID” of the user who watched it, the time when the user started to watch the video, the internet protocol address other devices connected to the internet use to identify the user’s computer (“IP address”), and the identifier for the video.

...

Google correctly argued that “the data should not be disclosed because of the users’ privacy concerns,” citing the VPPA, 18 U.S.C. § 2710. However, the Court dismissed this argument with no analysis, stating “defendants cite no authority barring them from disclosing such information in civil discovery proceedings, and their privacy concerns are speculative.”

Dang. Wish I hadn't watched so much Rick Astley. I hope Google tells the judge, "Never gonna give you up..."

Bill de hÓra responds to yet another RPC effort...

"JSON is the sweet spot of type driven interop"

http://www.dehora.net/journal/2008/07/03/arghpc/

This will coincide with OOPSLA in Nashville. John McCarthy will present.

http://www.franz.com/services/conferences_seminars/lisp_50th-birthday.lhtml

50th! Take that, other dynamic languages!

RabbitMQ and XMPP... Now get the best of both worlds, I guess, through this gateway.

James Robertson observes OnStar, the Pentagon, and your local transit authority losing control over their control freakishness...

This is like DRM, but with extra stupidity added in.

Because I am _real_ worried I might end up in Speed 3.

Responding to a thread on the erlang-questions list...

The problem we are discussing is processes B, C, D hold information X, Y, Z respectively; process A wants a coherent snapshot of X, Y,Z.

There are actually two slightly different cases depending on A needs "X Y Z as of *now*" (A, B, C, and D must all synchronise), or A needs "X Y Z as of *some* time in the recent past" (B, C, and D must all synchronise but can then send the information to A without waiting for A to receive it).

I like this problem because it is simple yet subtle. One way that it is subtle is that in "multithread" programming most people STILL think in terms of a single absolute time shared by all threads. (After all, there _is_ such a thing, the system clock. And yes, it's not exactly true, but it's close enough to make people _think_ it's true.) But when you start thinking about Erlang and especially *distributed* Erlang, you start realising that "now" is a pretty fuzzy concept.

Yes, the problem seems simple yet subtle. The downside is there are many unwritten constraints (or not) on any specific problem that could lead the solution alternatives one way or another. Unless you want to really dig into those, then the cost/benefit of one solution or another could be more or less off.

e.g. why not coordinate through an in-memory database? This could be reasonable, or not. We don't know enough.

Why not schedule the source processes to send a message on a periodic or scheduled basis? This could be reasonable, or not, and cut down the message traffic, which seemed to be a concern.

Why is sending fewer than N messages a concern? Why does one process have to collect the information? How much information? How tight is the deadline? Is "now" an actual timestamp or just some unknown point in time that a request has been received? How close to "now" do the other "nows" have to be with respect to each other? Can you widen that window if it would decrease the effort to build?

If synchronization across the processes is needed then is an "eventually consistent" approach reasonable if it lowers the effort to build?

Interesting stuff, but challenging to talk about in when the details are too abstract.

As long as I'm writing down my thoughts on this trip: I've been in two hotels in Belfast, the Hilton and the Radisson. Both are nice, close to the city center, and on the water.

They both have internet frustrations: neither have wireless in the rooms; the Hilton charges for wired internet in the rooms at ₤15 per 24 hours! When you pay that fee then they also throw in wireless _in the lobby_! Well, it's BT and the voucher is good for any BT provider in that 24 hour period. I found BT is the provider around some nearby coffee shops.

The Radisson at least provides free, but wired, internet. The problem then is the MacBook's adapter for UK plugs do not fit in the limited space above the immovable desk provided in the room! The nearest outlet that provides enough clearance for the adapter is across the room on the other side of the bed. If I had a 25' extension cord for either electricity or the internet, then this might be less frustrating.

(Let me update this with a warning: if you intend to use the internets with any expectation of getting bits back to your laptop, avoid the Radisson altogether. Band-width-wise this turned out to be simply unusable for long stretches.)

And so on to coffee: Caffe Nero is the best I've found in the city center so far, and the best I've found anywhere for a large chain. http://www.caffenero.com/

I've flown Continental Airlines twice this year-to-date. Thrice if you count the flight that was actually run by Northwestern, but I'd rather discount that one.

Continental has to be my top choice, for the food service alone. They serve hot meals, and a fair bit of it with each meal, that actually taste like real food.

I do think they recently took another inch out of the leg room though.

I can think of several airports to spend over a quarter of a day in that might even be somewhat pleasant. My own PDX would be high on that list.

Not making the cut would be Newark, NJ. Has this airport been even considered for remodeling since I was last here, about 25 years ago???

The most curious difference: the bars are run by the breweries. And so there is a "Miller's" bar and a "Budweiser" bar. Thankfully there is also a "Sam Adams" bar.

I guess folks in the NYC area do not hate _all_ things about Boston.

But what happens when you are traveling with a party with varying tastes?