A while ago TheServerSide.net published an article with Jeff Richter’s thoughts on the future of .NET assembly versioning.

If you read the article you’ll find that the Longhorn OS will seriously change the way that .NET itself is versioned. In fact, it turns out that to a serious degree the whole idea of installing “side-by-side” versions of .NET itself will go away when Longhorn shows up.

Oh sure, they have plans for a complex scheme by which assemblies can be categorized into different dependency levels. Some levels can be versioned more easily, while others can only be versioned with the OS itself.

What this really means is that .NET is losing its independence from the OS. In the end, we’ll only get new versions of .NET when we get new versions of the OS – and we all know how often that happens…

I’d say that this was inevitable, but frankly it was not. Java hasn’t fallen into this trap, and .NET doesn’t need to either. Not that it will be easy to avoid, but the end result of the current train of thought portrayed by Richter is devastating.

Fortunately there’s the mono project. As .NET becomes more brittle and stagnant due to its binding with Longhorn, we might find that mono on Windows becomes a very compelling story. mono will be able to innovate, change and adapt much faster than the .NET that inspired it. Better still, mono will remain unbound from the underlying OS (like .NET was originally) and thus will be able to run side-by-side in cases where .NET becomes crippled.

Hopefully Microsoft will realize what they are doing to themselves before all this comes to pass. Otherwise, I foresee a bright future for mono on Windows.

On the PeerCast website there is an FAQ in which they recommend turning off the Windows XP Firewall:

I got everything right with my broadcast, but no matter what I do, my stream can't get through. Should I get lost?
You are probably behind a firewall, if it is a personal firewall installed on your local PC, try turning it off. (Windows XP Pro for example..)

No wonder open-source is “more secure”, when they are actively running around telling people to disable the primary safety mechanism provided on Windows.

(to be fair, their blanket statement would apply to Linux firewalls too, but their example is Windows, which leads one to believe they prefer having lots of unprotected Windows machines on the Internet or something...)

Sabotage or just stupid advice?

If open-source people are as smart as they claim, they should be telling people to open only those ports required for the software, not to turn off all defenses and let anything through!!

Google has released a 20 year timeline of usenet newsgroup history, highlighting notable events along the way.

I find it very interesting to see the history of the “world's largest BBS“.

Personally I got involved in usenet in 1989 or 1990. I was working for a bio-medical manufacturing company, and managed to convince a local defense contractor to allow us to tap a usenet feed off them. The feed came through our 1200 baud modem, with us dialing into their system to transfer the data. Later they also allowed us to route email through their system over our much faster 2400 baud modems. Ahh, those were the days!

Why'd they do this you ask? Because we were both DEC VAX shops, and there was a hacker-metality brotherhood amongst VAX admins. (that's hacker in the good sense, not the dark sense) I don't think much of that mentality still exists in our industry, and that is a sad loss. I suppose it is the price of “progress“.

Prior to getting the usenet feed, I was a Citadel user. That was a Commodore 64 BBS that worked in a manner similar to usenet. It might have run on the Amiga too, but I don't recall for certain. Anyway, Citadel was a store-and-forward relay system like usenet (at the time), and so I was able to interact with people from all across North America via a local phone call. Someone in the area obviously made long-distance calls as a gateway, and my thanks go to that unknown benefactor!

To bring it back to the usenet timeline though, I think this timeline is interesting by itself. But it also should help us remember that the Web is just one thread in the much richer tapestry that is the Internet proper.

1. Less choice leads to better results.
2. Higher level languages and frameworks restrict choice.
3. Thus, higher level languages and frameworks should lead to better results.

The “less choice” statement flows from this article entitled Choice Cuts. Ignore the politics and focus on the research beneath the statement. That’s what is valuable in this context.

It is obvious that higher level languages and frameworks restrict choice, so I’m not going to cite a bunch of references for that. While many of these languages and frameworks provide a way to drop out to a lower level, in and of themselves they restrict choice. Just look at Visual Basic versions 1-6. Very productive, but often restrictive.

Whether the conclusion that higher level languages and frameworks will lead to better results is true or not is unknown.

Certainly there are examples where better results have been gained. This train of thought is lurking somewhere behind the software factories movement, and does seem quite compelling. Certainly many people using CSLA .NET with code generators have found radically increased productivity – and the combination of the two does restrict choice.

Yet there are countless examples (especially from the era of CASE tools) where the results were totally counter-productive. Where restriction of choice forced intricate workarounds that decreased productivity and made things worse.

Charles Simonyi contributed to an article on The Edge, essentially noting that there still is a software crisis and that low-level languages aren’t solving the problem. He argues in fact, that low-level languages like C#, VB and Java are a dead-end. That we must move to higher-level language concepts in order to adequately represent the real world through software.

This is the view of the software factories people and the domain-specific language movement. And it is rather hard to argue the point. There are many days when I feel like I’m writing the same code I wrote 15 years ago – except now its in a GUI instead of on a VT100 terminal. But the business code just hasn’t changed all that terribly much…

To look at it a different way, a software architect’s job is to restrict choice. Our job in this role is to look at the wide array of choices and narrow them down to a specific set that our organization can use. Why? Because having each developer or project lead do all that filtering would seriously cut into productivity.

Companies employ architects specifically to limit choice. To set standards and policies that narrow the technology focus to a limited set of options. The rest of the organization then lives within those artificial boundaries. There are many reasons for this, including licensing costs, training and so forth. I doubt that many people have considered the direct (presumably positive) impact of the reduction of choice however.

I’ve been working on an idea I’ve dubbed an Entity Description Language (EDL). My original motivation was to reduce the amount of plumbing code we write. Look at a typical Java, C# or VB class and you’ll find that less than 4% of the actual lines in the class perform tangible business functions. Most of the lines are just language syntax or pure plumbing activities like opening a database connection.

In working on EDL though, I’ve discovered that it is virtually impossible – and perhaps undesirable – to replicate the capabilities of C# or VB in their entirety. There are reasons why these languages use such a verbose syntax. They require verbosity in order to provide flexibility, or choice. Virtually unlimited choice.

If we now consider that limited choice is better, then perhaps the fact that something like EDL restricts choice is only good…

OK, I figured it out (I think)

    [NonSerialized]

    EventHandler _nonSerializableHandlers;

    EventHandler _serializableHandlers;

    /// <summary>

    /// Declares a serialization-safe IsDirtyChanged event.

    /// </summary>

    public event EventHandler IsDirtyChanged

    {

      add

      {

        if (value.Target.GetType().IsSerializable)

          _serializableHandlers =

             (EventHandler)Delegate.Combine(_serializableHandlers, value);

        else

          _nonSerializableHandlers =

             (EventHandler)Delegate.Combine(_nonSerializableHandlers, value);

      }

      remove

      {

        if (value.Target.GetType().IsSerializable)

          _serializableHandlers =

            (EventHandler)Delegate.Remove(_serializableHandlers, value);

        else

          _nonSerializableHandlers =

            (EventHandler)Delegate.Remove(_nonSerializableHandlers, value);

      }

    }

    /// <summary>

    /// Call this method to raise the IsDirtyChanged event.

    /// </summary>

    virtual protected void OnIsDirtyChanged()

    {

      if (_nonSerializableHandlers != null)

        _nonSerializableHandlers(this, EventArgs.Empty);

      if (_serializableHandlers != null)

        _serializableHandlers(this, EventArgs.Empty);

    }

I temporarily forgot that C# makes you invoke the delegate directly anyway, so having a separate clause in the manual event declaration isn’t required. I still think it makes the code easier to read, but functionality is king in the end.

Several months ago I posted an entry about the new VB syntax for manual declaration of events – specifically showing how it can be used to solve today’s issue with attempted serialization of nonserializable event listeners.

Subsequent to that post, I posted a follow-up with a better version of the code, thanks to input from a reader.

At the moment I am working through some eventing issues in both VB and C#, and I’ve found what appears to be a troubling limitation in C#.

In the new VB manual declaration scheme we have the ability to manually raise the event using the backing field. This allows me to have two backing fields - one serialized and one not as shown in my follow-up post. This is really nice, because it means we can retain serializable delegate references, while dropping nonserializable references.

Unfortunately, it doesn’t appear that the C# syntax allows us to control how the backing field is invoked. It appears that only one backing field is possible, and it is invoked automatically such that we don't have control over the invocation.

If we can’t control the invocation, then we can’t invoke both the serialized and nonserialized set of delegates. This will force the C# code to treat all the delegates as nonserialized, even those that could be serialized.

Of course I’m researching this for CSLA .NET 2.0. Wouldn’t it be a joke if this time the C# framework had to have some VB code (since last time it was the other way around)?

Anyone have any insight into a solution on the C# side?

Want to hear about SOA and/or Indigo? Eric Rudder, Don Box, Doug Purdy and Rich Turner are all speaking at VS Live (as is yours truly).

Even if you like me, are rather skeptical about SOA, the fact is that Indigo is coming.

Don't let the SOA hype fool you. Indigo will impact you if you use .NET.

Personally I look at Indigo much more as a replacement for remoting and DCOM, along with integrating the WSE stuff into Web services. Because of this, Indigo is a very important thing to me - and to anyone building client/server or n-tier distributed systems in .NET.

Indigo alters the way objects are serialized, the way data is marshalled across networks and more. It is pretty extensive, and is going to be harder to abstract away than either asmx or remoting have been. This means we, as consumers of the technology, will need to understand more of it than we have needed to with existing technologies.

Since VS Live has a whole day on Indigo, this is a chance to get a good look at what's coming and assess what it is going to do to you.

And of course while you are at VS Live, you can attend my distributed object-oriented workshop

Dan Miser blogs that there's a new version of Trillian out there. Off to download we go  - and I suggest you buy it! It is well worth the money!

You can now get details about, and download the beta of, Microsoft's new AntiSpyware software at this location.

I was going to post this on my personal blog, but it occurred to me that it is technical enough in nature to fit here. 

EPIC is a flash video (which has been out for a while now) that portrays the future of media. It is scary, but interesting. Moreover it is thought provoking.

Certainly the web/blog/wiki thing has driven down the value of professional writing. Magazines (and vendors such as Microsoft) are paying less and less for content. Why should they pay when tons of people will produce content for free? Why should advertisers go with established publishers when some blogs outstrip them in readership?

Book sales are down. Even factoring in the dot-bust and the Bush-era recession of the past few years, book sales are down from where they should be. Who needs to buy a book when you can get so much online for free through a quick google search.

It is easy to look at Epic from a technology perspective, but it is the larger social perspective that I find interesting and troubling. And the social effects are real and there's active debate.

Take the controversy over wikipedia.org for example - the encyclopedia business is under siege by who? Us. Anyone with a fact can share it with the world, without going through a formal company or process. Without any opportunity for anyone to make money on it. On one hand this is good, but on the other it is bad. Who’s going to fund archeological research? Who’s going to do the hard parts of finding facts? For free?

In the technology space, many of us blog things – including me. In many cases these are things that might have been paid articles prior to blogging, but now we gleefully put them on the web for free. That's fun for a while, and is good for notoriety, but in the long run it isn't sustainable.

Several people (friends or acquaintances of mine in both the Microsoft and Java spaces) recently have indicated that they are done writing - books, articles - they are done. This is troublesome. Is Atlas shrugging? Will the content of the future consist merely of the myriad voices of mundane souls?

Epic portrays at least one alternative, where it is at least possible for an author to get paid for their craft. Whether that is a realistic model doesn't matter as much as the fact that some model must be found.

Because we're not talking about just technical authors. We're talking about fiction. We're talking about music, and eventually movies. How will content creators get paid to do their work when random people do it for free? Will true artists bother? Do we care? Perhaps the people doing it for free are as good or better?

Perhaps they are just good enough, which is even scarier. That, after all, is the primary sin people ascribe to Microsoft. That they aren't the best, but rather are just good enough – leaving us stuck living in a “good enough“ world rather than a really kick ass world.

I don't necessarily buy that viewpoint on Microsoft. Having used various flavors of Linux I don’t see that as the “kick-ass world” I’m personally looking for anyway. But it is easy to look at reality TV and see where everything could sink to that level.

Epic raises serious questions that only time will answer...

In my previous entry Randy H notes that Microsoft has a different approach to marketing:

MS has some incredibly talented marketers. The Technical Product Manager role is essentially a marketer that helps to determine what features go into products and how things should work. To me, that kind of marketing has a lot of value. I wouldn't dismiss the role of marketing in our greatest technology companies. Wasn't .NET a whole lot of marketing as well?

While it is true that Microsoft has a unique approach to marketing, they really aren't much different than anyone else. While .NET was as much marketing as anything else (since the ".NET" got slapped on _everything_ for a while), the reason it has been successful is due to its technical merits.

Notice that the ".NET" label is fading already - Visual Studio 2005, Visual Basic 2005, etc. No .NET left in the product names at all. My guess is that ".NET" the term will fade away into the same marketing hole that swallowed up Remote OLE Automation, MTS and soon SOA.

I have always found it amazing when Microsoft is said to have this "great marketing machine". In many ways they are the worst marketers out there. Certainly far, far worse than Apple or IBM for instance.

Apple has the trendy thing going, and has for a very long time. Microsoft has never been trendy or fashionable or cool or hip. But Apple sure is hip, and it shows in their iPod sales. For some reason though, having powerful marketing in the "cool space" doesn't translate to widespread use.

IBM has those really kick-ass commercials that juxtapose business situations with strange solutions. And prior to that they had the cool commercials showing non-tech scenarios that were just metaphors for IT issues. Very cool and very smart stuff. Very effective too, as IBM’s global consulting arm has become large and influential due to that kind of marketing.

Microsoft has never had anything remotely similar to “real” marketing like that. Microsoft’s marketing has always been more subtle and focused on technologists. In reality, Microsoft’s marketing has always been more grass-roots, much like the open-source world.

And there’s some humor for you. The open-source world has apparently decided that it too needs marketing. Even if you make no money off your work, you certainly want the fame/notoriety – and to get fame you need people to use your stuff rather than your competitors’ stuff (regardless of whether they are commercial or OSS).

At the same time, Microsoft really wants to move into the enterprise space, and so they have been trying to figure out how to do “actual” marketing along the lines of IBM. And they want to sell consumer items like the Media PC, so they’ve been struggling to figure out how to be hip like Apple. Hopefully as they do this, they’ll manage to continue the MSDN and TechNet-style marketing to the technical community. We’ve been the bread-and-butter for them over the past 12 or so years after all.

Don Box put out his predictions for 2005, including #3 which states that the term SOA will be replaced by some new hype-word invented by the marketing wonks of various software and industry analysis companies.

As I said months ago, the S in SOA is a dollar sign. SOA is much more hype than reality, which means it is created and defined by marketing people far more than it is by actual computer scientists or engineers.

As is often the case with over-hyped concepts, the terms related to those concepts rapidly become meaningless. What is SOA? Depends on which vendor you ask. What is a service? Depends on which vendor you ask. It is all a meaningless jumble here at the start of 2005.

Of course the concept is too valuable to marketeers[1] for them to give up just because a term has been lost. So I am sure Don is right and marketing groups at Microsoft, IBM, Gartner and many other organizations are busily working to decide on the next term or terms to use for a while.

So for better or worse SOA itself isn’t dead, but I agree that the term is living on borrowed time.

[1] Yes, I know the term is marketers, but that extra “e” in there makes it sound so much more, well, Disney somehow