Return of the Dog Shit Girl

Apparently my Dog Shit Girl (DSG hereafter) post resurfaced on the blogosphere and comments are snowballing. Well, this proves that she won't be forgotten. As I wrote in one of my comments: attention cuts, retention bleeds.

Update:

Apparently the resurfacing was due to being mentioned on Fark. Go check out the massive pile of comments and pictures gathered there. The funny thing is that they are fascinated by her middlefinger just like Korean netizens were.

Farkers have clicked on the above link 34528 times.
Oy. That's a lot of farking around. – Don Fark.
 
And here is the Technorati link for BoingBoing mention. I guess Mark doesn't subscribe but reads Fark.

Comment on Microsoft Embracing RSS

Others have already discussed this news into realms of fantasy and paranoia so I'll just point out one aspect I think no one has addressed yet: security.

Blogging and syndicated data technologies in general have yet to fully test the fires of hostile computing world. As their prime time nears, they will be subject to abuse and exploitation.

For example, the primary mechanism behind podcast, RSS enclosure, can be used to deliver worms and worse to the desktops. If there are any vulnerabilities in iPod (or any MP3 player hooked up to podcast sync client) codec, then podcasting is a good way to deliver overflow inducing content.

While some might consider social networking aspect of blogging and syndicated data as enhancing security, I see it more as a potential problem because I think trust itself is a primary source of vulnerability.

If you subscribe to 1000 feeds, you are hanging on a chain with 1000 links. Each of those 1000 links (feeds) are potential targets for hackers to attack to gain control over its content. All they need is one vulnerable feed hosting server to change what is delivered to your desktop. If you are using an insecure news client that pools news items from multiple sources, a hacker in control of Ponzi's Schemes feed (hi Ponzi :-)) will be able to send out posts that looks as if they came from the American Express feed.

Some of these problems are easy to fix, some are not. But it's difficult to fix them if you haven't thought about these issues and not many have so far because we were too busy enjoying the heat of creation and smelling the morning rose petals.

I think engineers at Microsoft who had more than their fair share of security-related criticisms will be able to help out in enumerating and addressing the security issues in blogging and syndicated technologies.

That's all.

Update:

FYI, this post is being slashdotted today. You can find their comments at Slashdot and AlterSlash. So far I am happy to see this blog withstand being Slashdoted and Farked at the same time. My fingers are still crossed though. Back to my work pile.

Biscuit – C++ recursive-descent parser framework

Biscuit is a C++ template-based recursive-descent that combines YARD and C++ Metaprogramming finite state machine to write, in C++, reasonably readable EBNF. While I suspect not all the kinks and bugs have been flushed out, I thought the project was interesting enough to keep an eye on.

For example, following EBNF grammar fragment:

group  ::= '(' expression ')'
factor ::= integer | group
term  ::= factor (('*' factor) | ('/' factor))*
expression ::= term (('+' term) | ('-' term))*

is written in biscuit like this:

struct expression ; // magic!
struct group  : seq< str<'('>, expression, str<')'> > { };
struct factor : or_< integer, group > { };
struct term  : seq< factor, star< or_< seq< str<'*'>, factor >, seq< str<'/'>, factor > > > > { };
struct expression : seq< term, star< or_< seq< str<'+'>, term >, seq< str<'-'>, term > >

And here is a XML comment micro-parser:

typedef seq<
  str<'/','*'>,
  star_until< any, str<'*','/'> >
> c_comment;

which can be used like this:

if (match<c_comment>("/* hello, biscuit */")) {
  //…
}

If you are not attracted to the fatal beauty of C++ template programmng, nevermind.

Too Easy to Intervene

Read Billmon post on forewarnings we had about the Iraq invasion. The quote he ends with, in particular, hit me squarely:

The [Unified Quest] experience left a few, such as Adm. Bien, believing that the best course of action would have been not intervening at all. "We're developing a force that makes it almost too easy to intervene," says Adm. Bien. "I am concerned about America pounding herself out."

If we have to intervene, then the wisest thing to do might be to hit and run instead of staying around to fix what we destroyed. In other words, don't mix national security with politic, ideology, religion, economy, nor conscience.

P2P Supreme Court Ruling

While most of my collegues will disagree with today's P2P supreme court ruling and I fear the ruling will lead to abusive litigations by record labels, I can't bring myself to disagree with the judges in principle.

Most people used P2P services for illegal file-sharing. It would be silly to suggest that P2P tool vendors and service providers did not know about the ongoing illegal use of their tools and services. They were aware and turned the other way. Some of them even went further by introducing features that interfered with efforts record label companies made to directly prevent file sharing.

This doesn't mean that you are liable for every abuse of some well-intended software you released to the world. But you will be liable if you become aware and did not take reasonable steps to prevent abuse.

In the end, the choice is between destroying the music industry or stiffling a promising sector of the technology industry. Musicians have the power to create wonders for our ears. We the engineers have the power to turn their economic world upside down.

All the talk about how P2P can revolutionize the music industry and fairly reward musicians are just that, talk, because it's not their basket of eggs that is being threatened. If they are so sure, why don't they prove their wishful economic theory themselves instead of sitting on the sideline and yelling at record labels to jump across the chasm of uncertainty?

It is true that DRM solutions out there are terrible but IMHO that's OUR problem. We failed to come up with a more reasonable solution and commerical online music services failed to properly inform their customers on the limitations of the service they are providing. Frankly, I think they intentionally misrepresented the service they sold and profitted unfairly. Otherwise, people wouldn't have bought hundreds of songs through iTunes and they would have gotten upset when they switched machines.

We engineers cannot and should not escape our responsibilities with a few paragraphs of AS IS and IN NO EVENT SHALL [we] BE LIABLE. Power to create is not a license to unleash anything we can imagine into the world. Yes it will be stiffling, sometimes unbearably so. Can we prevail in the end? I think so. We are engineers after all.

BTW, here is the best interpretation of today's ruling I found.