2008-07-29

(S)TM

http://www.theregister.co.uk/2008/07/28/sun_dziuba_tm/

Very, very, crude language, but I'm excited that something I learned about on the side while learning Haskell (or trying to, because I couldn't figure out Monads well enough) is probably coming to hardware!

STM (Software Transactional Memory) was a really nice concept that essentially does to threading and concurrency what commit buffers and ACID properties do to database programming.  You know the database engine will take care of concurrency in database transactions, right?  STM systems will do the same for threading, except Sun is now talking about HTM (Hardware TM) and HyTM( Hybrid TM).  Cool!

STM is based on the premise that you mark out sections that are supposed to be atomic -- that's the "A" in ACID, in case you forgot -- and the back-end system will ensure that either *all* of that will happen or none of that will happen (it'll be rolled back).  What the system does is keep track of every variable you *read* and log every write you make inside the atomic block.

When you exit the atomic block, it double checks every variable you *read* to make sure it is still the same.  If they are all exactly the same, it means that none of the other threads did anything that would have conflicted with your data, so your "transaction" is committed.

However, if any of the variables you read inside the block have changed, it has to roll-back your "transaction" and maybe re-try.

In other words, optimistic concurrency control.  (Curiously, most modern Version Control Systems are also based on the same idea... go figure!)  Maybe it's time to re-start my aborted attempt at learning Haskell...

PS:  And this bit is absolutely priceless:

What I would have learned had I been more dedicated to my education were the two fundamental facts about multi-threading with locks:

  • 1. You're going to fsck it up.
  • 2. If you think that you haven't fscked it up, you have. You just don't know it yet.

2008-07-28

(malware) lest we forget...

(small one, so I quote the whole thing; apologies):

----- start quote from http://apache.slashdot.org/comments.pl?sid=626521&cid=24344659 -----

Dear Open Source Community,
We were wrong and we're sorry. As a token of our apology, here's a nice big wooden horse.

Sincerely,
Microsoft

----- end quote -----

main story: Microsoft Blesses LGPL, Joins Apache Foundation
Bruce Perens says there's much reason for caution: http://apache.slashdot.org/comments.pl?sid=626521&cid=24342531
Microsoft's 2002 plan to sue Apache: http://apache.slashdot.org/comments.pl?sid=626521&threshold=5&commentsort=3&mode=thread&cid=24346261

2008-07-21

(malware) why you should avoid Windows formats

There's a new virus out that "searches for MP3s, transcodes them to WMA format, wraps them in an ASF container, and adds links to further copies of the malware, all without modifying the .MP3 extension": http://it.slashdot.org/article.pl?sid=08/07/18/145223&from=rss

The real insight here is at http://it.slashdot.org/comments.pl?sid=618545&cid=24242285 , which explains why ASF is like the ActiveX of multimedia! It's a very short comment, so I'll take the liberty of reproducing it here:

For those of you who think this is just a troll, or are just unfamiliar with ASF:

Advanced Systems Format is a Microsoft-defined container format for audio and video streams that can also hold arbitrary content such as images or links to Web resources.

If a user plays an infected music file, it will launch Internet Explorer and load a malicious Web page which asks the user to download a codec, a well-known trick to get someone to download malware.

It's like the ActiveX of multimedia wrapper files. A security nightmare? You bet. Does it still depend on user stupidity? Well, yes.