25 posts tagged “software”

This is all over the tech news.  Here's a link to one of the plethora of stories about the transaction.

This is a pretty big deal to the tech industry, so it's been widely covered.  I think it will be a good thing, and I think most of the angles have been discussed elsewhere already, but there are two implications of this sale that I haven't heard anything about yet, and I'll touch on each briefly.

1) What does this mean for Oracle? 
Each of the major databases has it's paired language.  Maybe it's not official, but if you use the language the odds are pretty good (though definitely not certain) you're using the matching database as well.  For example, if you're using anything .Net, MS SQL Server is probably your database of choice.  If you use PHP it's a good bet you prefer MySQL.  In the past, Java was Oracle's language.  Most of the Oracle development samples are in Java, and Oracle seems geared to appeal to Java developers.  A large percentage of enterprise Java applications talk to Oracle. 

This changes the game a little bit.  Now Java and MySQL are under the same roof.  I would expect Java's support for MySQL to improve significantly, made possible in part by changes to MySQL to specifically make it more Java friendly.  It's just natural.  If I were Sun one of the first things I'd do is build a package that makes it exceptionally easy to install the Java runtime, MySQL, and some good GUI management tools onto a Windows server, and then use that server as deployment point for the Java runtime on the local network.

Of course, Oracle isn't just going to disappear any time soon, and the Java developers aren't going to convert overnight en mass.  In fact, Oracle today also bought BEA Systems, in a deal worth 8 1/2 times as much as the MySQL deal (the MySQL deal, though, is a lot more interesting).  But this does have the potential to diminish Oracle's prospects in the long term.  They'll still make money, but maybe not quite as much as they would have.  And look for Oracle to do something in the language space to help themselves have a natural language partner again.

2) What about Monopolies?
Whenever two large companies merge this always comes up.  This time it's had a bit of a pass.  Neither Sun nor MySQL by themselves were big enough to merit such attention, as an open source product there's no way to count MySQL installations and therefore no way to prove market share, and the two businesses are such that this is a no-brainer that there isn't a problem. 

All those circumstances change once the merger is completed.  We end up with a landscape in which there are two big open source players in Sun and RedHat.  Neither of these companies is an any danger of becoming a monopoly by itself.  Between Microsoft, IBM, Apple, and Google there's just too much competition for their offerings.  But what if at some point Sun wanted to buy RedHat?  Or vice versa?  Would the feds try to block the merger to avoid forming a monopoly in the Open Source market?

I think that scenario is very unlikely; but it is possible even if remotely, and it's worth mentioning because of some of the issues it raises.  For example, how can you be a monopoly if the code for your products is freely available for anyone to sell and compete against you?  Often a requirement for mergers of large companies is that a company make certain changes to it's product, to make it harder for it to abuse a potential monopoly.  How can you require such a change of a company when the company is dependent on volunteers to implement them?  If an open source company grows to the point where it's featured project edges out competition almost completely, could this company be held responsible even though they are neither the creator nor owner of the program in question?

There are more questions, some harder to answer than others.  For example, you certainly can get into monopoly trouble if your freely available product drives out competition and you have another complimentary non-free product.  It's called predatory pricing.

The Hook
Let's bring these together.  What if Oracle bought Sun?  That would shore up Oracle's language gap and eliminate a competitor in one go.  In fact, Oracle has already tried to buy MySQL in the past.  Oracle is certainly big enough to do it, and Sun's may find themselves vulnerable at some point not too far in the future, assuming they'd even fight it.  Oracle has been responsible for a lot of developers using Sun products, and both Sun and Oracle have a deep dislike for Microsoft that makes them natural allies.  But that might raise some real anti-trust issues, with the potential demise of MySQL at stake.

Imagine you go back in time and find yourself in an era just before electronics or 'the wireless'.  Say shortly before 1900.  You meet someone there, and he notices your cell phone.  You try to explain to him what it does, and how it works.  You tell him that in the future nearly everyone will carry the device, and it allows you talk to people over great distances almost as if they were standing next to you.  You explain that the device emits an invisible signal, and there will be towers all over that receive the signals and re-send them to whoever you are talking to.

This is where it gets interesting.  I think this would cause your historical friend to stop you for a moment.  "You mean you can make your voice heard on the other side of a continent as if your were standing there, but it has to stop at some kind of tower first?" 

Not that he couldn't understand.  You just explain that the signal deteriorates over distance.  But in his mind getting that signal into the air in a way that can be retrieved in the first place is the big hurdle.  So big as to be almost unimaginable.  Once you've accomplished this increasing the distance would seem to him a comparatively small problem. 

This kind of problem happens all the time in software.  You'll get questions like "Why can't I send this 15 minute video to 40 people via e-mail?" or "What do you mean Excel only supports up to 64,000 rows?"  There's a lesson in there somewhere for software developers, but I'm too lazy to spell it out right now.  Probably something about how software developers relate to users.  Or how to manage user expectations.  Or publish limitations.  Or something. 

There's an old saying, "Less is more."  This is especially true in the programming world, where size is the enemy.  Programmers are brainwashed with the "keep it simple" mantra almost from the first moment we enter the field. 

But sometimes things get turned around.  For example, how much code does it take to implement quick sort versus a bubble sort?  Obviously quick sort is a lot more complicated.  This means it's a lot more susceptible to errors in the implementation, it takes more time to build and maintain, and it adds size to your code base making it that much harder for developers to internalize.  So keep it simple right?  Go bubble sort!

Not so fast.  Take away all that and which algorithm would you rather have working behind the scenes in your application?  There's no contest:  quick sort is significantly faster.  Even with the extra complexity it's almost always the right choice.

So how do you know where the balance tips?  When to use an elegant algorithm like quick sort and when to go for simple code like bubble sort?  Well, as it happens, I've never personally implemented quick sort, and probably never will.  But I have written a number of programs that rely on it, because these days quick sort is the underlying algorithm used to sort collections in .Net.  So while I don't have to write it, the correct algorithm is done for me.  This means I'll never write another bubble sort, either.

The goal should always be to avoid duplicate code.  If this is done to a sufficient level, the complexity matters much less.  You don't need to understand how quicksort works to call Array.Sort() in .Net, and the code that makes that work doesn't add bloat to your application because it's generic enough to handle just about any array, and it's hidden away in a library that's rigorously tested and hardly ever changes.  This makes it possible to have very simple and maintainable code that performs very well.

Of course, you can't insert your own code inside the .Net framework.  But if you're working on a project of any significant size you should have libraries for common and important tasks.  These libraries should be well named, as generic as possible, very well tested and documented, and change rarely.  And they should be full of quick sort code rather than bubble sort code.  Once you have a library, don't write code that uses it unless you can explain the code to a six year old, or worse, a sales director.

In late 2004 I took a job as a VB.Net programmer.  At that point my only exposure to Visual Basic had been a six week segment of a class in college covering VB6.  Most of the rest of my college work was done in C++.  My employer knew this, but hired me anyway.  I hated VB6 then, and I hate it now.  Needless to say, I was very nervous going into that job.  Fortunately, I fell in love with VB.Net very quickly. 

This is why it pangs me so to see the bad wrap VB.Net still gets today, especially when compared to C#.  C# does have some admitted advantages over VB.Net, but VB.Net is sometimes not even given full consideration.  I think this reputation is undeserved, and largely based on VB6' well-deserved reputation as a 'toy' language.   I want to lay it to rest; VB.Net doesn't deserve the same dis-respect as VB6, and here's why.  Below is a list of improvements for VB.Net that were not available in VB6.  I'm talking real language improvements, not just API classes you can use because they're in the CLR.  These are reasons why VB.Net deserves to be considered a real, grown up language:

• Real Exception handling.  No more On Error Resume Next (unless you really want to), and none of the "fake" exceptions you saw with Err.Raise.  VB.Net fully supports the try/catch/finally constructs.
• Short-circuit logical operators.  VB6's 'And' didn't behave the same as C++'s '&&'.  Many programmers are not aware that VB.Net has new logical operators that mimic the functionality of '&&' and '||'.
• Better OOP support.  VB.Net still supports modules, but it treats them as a construct called a 'static class' in C#.  In addition, you create real instances of classes and structures.   They support inheritance and polymorphism.  Even operator overloading is allowed now.  The only thing missing for complete OOP support is multiple inheritance, and that's not available in C# either, unless you count interfaces (in which case VB.Net has it as well).
  
• Option Explicit on by default. Most good VB6 programmers used it anyway, but now it's on by default.  And you don't see many good VB.Net programmers using variant types anymore, either.  When I see a new variable declaration, I expect to see a type name right there as well.
  
• Generics.  Once limited only to C++ templates, VB.Net gained the ability to use generic types for classes and methods at the same time as C#.
  
• Lambdas.  VB9 (Visual Studio 2008) has support for inline lambda expressions.
• Function Pointers.  Okay, not really pointers, since no managed language has true pointers.  But there is a construct available for using the managed address of a function, or passing a function as an argument to another function.

VB.Net may have a few quirks, but so does any language.  These days it deserves the same consideration as the big boys.

As long as there is software, there will be bugs.  This is an axiom every programmer lives by.  A first draft of a portion of software is rarely any better than the first draft of a similarly-sized literary work.  Not that I'm equating source code to poetry, but there are similar requirements.  There will be typos that must be fixed.  The cadence must be just right.  And a programmer must pay even greater attention to detail.  A new piece of code could have subtle consequences far removed from the point of creation.  A good percentage of a programmer's time is spent fixing these little problems.

Nevertheless, when a programmer writes new code there is a certain expectation in his mind, before it's tested even once, that the new code works to a certain extent.  After a few rounds with a debugger that expectation is much increased.  It's not so much that a programmer wraps his ego in his code as it is a natural aversion to making mistakes.  People don't like to make mistakes, and programmers are no exception.  Programmers want to be able to take pride in their work, just like anyone else.  They need to believe that their product has quality.

But as long as there is software there will be bugs, and that expectation for code to work is always balanced with the knowledge that something in the code is still wrong.  These two thoughts are constantly at war in a programmer's mind.  He knows clearly what he intends his code to do, he knows the language he's expressing it in, so it should work exactly as he expects.  At the same time he knows this is a lie for every piece of code of any significant size he's ever written, and somewhere in this code there is a bug such that under the right conditions the code just might behave differently.  A programmer has to believe he knows what he's doing, or he will never be able to accomplish anything.  He also has to believe he is essentially incompetent, or he'll deliver code that was never adequately tested.

It's easy to see now why programmers have a reputation for burning out.  Given this situation, there are a limited number of possible outcomes.  If this state of paradox continues forever it will cause increasing stress, leading a programmer over time to come to hate his task and seek a new profession.  Burnout.  The alternative is that one side must become dominant over the other.  If the programmer believes more and more that he is essentially incompetent his ego suffers.  He is defeated.  He will, again, come to hate software development and burn out. 

The other option is for the programmer to believe more and more that his code is perfect.  In this case you end up with another programmer stereotype:  the arrogant rock-star.   If a programmer has the skills to back up this self-image they can go a long way.  The really great ones will last out their careers.  The somewhat great ones end up in management.  If a programmer doesn't have the required skills they'll consistently deliver poor code, and eventually lose their job and move on.  This isnt' exactly burnout but has many of the same symptoms, even from the point of view of the programmer.  And it still contributes to the image of programmers having a short shelf-life.

Of course, these observations are not guarantees.  This is a situation where the ever-changing nature of the industry helps.  If you have to learn a new language or a new environment every couple of years you never really attain expert status in that system.  You're always on the front end of the learning curve, and that makes it easier to accept your failures.  Of course this has it's own negative effect, and can lead to a different kind of burnout.

There are other ways to avoid burnout.  You can look for projects that reduce the stress caused by the paradox.  A programmer may work on a large project, and then spend several years maintaining that code base.  For a fresh programmer that's a frustrating situation, but for a programmer approaching burnout it's a chance to relax.  Once the project enters the maintenance phase the programmer has no learning curve and the errors he fixes were mostly committed by others.  When the cycle finally ends the programmer is refreshed and ready to move to something new.  That's just one example.  What works for one programmer may be different than what works for others.

Many programmers will also find a natural balance.  The paradox is still there, but they've found a balance that doesn't produce unmanageable stress and still lets them keep their edge, both in the need to be constantly self-critical of their work and the confidence required to produce good code in the first place.  Burnout-level stress also takes time to develop, so those who don't find a good balance may be able to outlast the effects.  But as long as there is software there will be bugs, and and long as there are bugs programmers will keep pulling their hair out.

If you're not a programmer, specifically a .Net programmer, this will likely be a pretty boring post.  Fair warning is given.

I just found this link and I wanted to share it.  On one hand this isn't a very big deal.  MFC included source code, and I can and do step into all the time, often when I don't want to or care (Hopefully they'll be smarter about that with .Net).  On the other hand, it's pretty cool, for a few reasons:

1. The option wasn't there before in .Net, so this is a new capability for .Net framework developers.  There are some pretty complicated methods that do a lot of 'mystery' work behind the scenes (I'm thinking databinding here).  It will be nice to explore those. 
   
2. This could potentially be a huge boon to the mono project.  While the license will likely technically prohibit the mono team from even looking at the code for liability reasons, I wouldn't be surprised to see Microsoft look the other way on this.  They already have a relationship with Novell, and have basically contracted Novell to do the Linux Silverlight implementation.  It's to Microsoft's advantage to allow the mono folks to take advantage of this code.  That's exciting for me, because I would love to be able to build a .Net Windows app and then port it to Linux with very little work.
   
3. There are new capabilities in Visual Studio that let you take better advantage of the framework code than you could under MFC.  Now when you pause execution of a running program while debugging you can see the whole call stack, and step into the code at any level.  Or you can step out up to any level.
   

My favorite in that list is the mono project benefit.  Mono has come a long way already, but it still lags behind far enough that I don't recommend it.  Unfortunately this won't help them close any of the many open issues with 2.0 implementation, because the released code will be for the 3.5 framework.  But when they begin working on the 3.5 implementation hopefully it will be able to proceed faster, and with better quality.

So you're giving ASP.Net a whirl.  Congratulations!  ASP.Net is a pretty nice platform for developing web applications.  It has a lot of power and is pretty easy to use, once you get to know it.  However, the model for programming in ASP.Net is different than some other languages you may have worked with; if you're not careful you can end up making serious mistakes, making things a lot harder than they need to be, or just deciding that the platform is absolutely horrible for reasons that are completely, well... wrong.  This is especially true if you come from a Classic ASP background, because ASP.Net is deceptively similar in many ways and it's easy to fall into old-- and now bad-- habits.

Let's get started.
 
We'll begin with an environment like Classic ASP or PHP.  They may seem to be very dissimilar languages, but they have some similarities in certain areas.  I'm not talking about object names or syntax, but the model through which the code is interpreted.  They happen to share a model that looks something like this:

1. The browser sends a request for an .asp or .php page to the server.
2. Because it's a .asp or .php file the web server knows to pass the file through the ASP or PHP processor before sending it on.
3. The ASP or PHP processor will read through the file. Anything in special tags (<%, <?, etc) is interpreted on the fly, everything else is sent on as is.
4. Code segments that you want to reuse across your site are placed in additional ASP or PHP files that are included with the main page.
   

That's straight forward enough, so now let's see how this compares to ASP.Net.  The ASP.Net model looks something like this:

1. The browser sends a request for a .apsx file to the server. (a few other extensions are possible as well)
2. Because it's a .aspx file the web server knows to pass the file through the ASP.Net processor before sending it on.
3. The ASP.Net processor will read through the file. Anything in special tags (<%, <?, etc) is interpreted on the fly.  There are some new special tags that must be transformed to HTML and may mean additional code located in a .dll file is executed.  Everything else is sent on as is.
4. Code segments that you want to reuse across your site can be placed in additional .aspx files, or in a master page, custom control, web part, or class.

As you can see, it is very similar.  With ASP.Net you can include all your code in the .aspx file, use only straight html and <% tags, and ASP.Net will be almost identical to the first model above. In short, it has all the same capabilities you'd expect to find in a language like PHP or ASP, or at least it can be used in the same way.  There are, of course, differences in language constructs and syntax (you can't, for example, slap an x on the end of a .asp file and suddenly start using ASP.NET), but the point is you can treat ASP.Net just like you would treat PHP or ASP and get the same results.

If you're reading this article, you may be thinking that you've seen enough.  You were all set to try ASP.Net and now I've talked you out of it.  You already know a language like PHP or ASP, and since this language is the same, why should you care?  You can go on coding like you always have.   There are a number of answers to this question: more ways to re-use code, faster development times by using the new tags that automate common tasks, the ability to separate your code from your markup/presentation, and performance.  Just because you could use ASP.Net the same way as PHP or ASP doesn't mean it is meant to work that way.
 
Performance

I'll begin with performance.  This is the least reason to use ASP.Net, and I'm not even sure it's really there anyway, but performance does matter.  For a desktop application cpu cycles and ram are plentiful, but for a web application good performance can be the difference between needing one web server or a server farm running your app.  To understand the potential performance gains of ASP.Net you have to learn some history.  I'll try to be brief. 

In the beginning was machine code.  And from machine code eventually came the compiled and interpreted languages we have today.  Compiled languages are generally considered to be faster than interpreted languages.  I'll leave that debate for another time, just know that in the beginning of the web it was a generally accepted fact.  When the time came to create a server-side web language, performance being absolutely critical in those days of 33Mhz processors, a compiled language was chosen.  Thus we had C++ cgi programs driving pages.  Unfortunately, it turns out there is some overhead in creating a new process, and web servers typically will receive numerous requests for very small programs resulting in many many processes and a lot of overhead. 

A little time passes.  Machines and interpreters get better and faster.  It was discovered that the penalty for creating the processes in a web page was greater than that of an interpreter running in process with the web server.  This brings us to the present, where interpreted languages like PHP, ASP, Ruby, and Python are all the rage for web development.  You don't see as much cgi anymore.

This matters to ASP.Net because the application code lives in a dll that is compiled all the way to native machine language,* but runs in process with the ASP.Net processer (the .Net framework).  This means you should get a performance boost just for using ASP.Net -- the best of both the compiled and interpreted worlds.  In practice, I've noticed you may end up sending more requests to the server because every action can cause the page to be rebuilt.  In my opinion this largely makes a wash of any performance benefit, but should still be considered a "good thing".  The additional requests can generally be seen in terms better response to the user or new features added by the developer.  You get what you pay for, so to speak.  This fits with the history of computer programs; as soon as we find a way to get more computer resources developers will find something to do with those resources.

Controls

Early I mentioned some 'new tags' you can use with ASP.Net.  Lets talk about how they fit into the picture.  These new tags are called 'controls'.  Here are a few examples: <asp:gridview>, <asp:literal>, <asp:repeater>, <asp:panel>, <asp:textbox>.  You can make your own controls, which is an important part of ASP.Net.  You can think of these controls, in one sense, as a transformation.  The ASP.Net processor will read the controls and transform them --or render them--  into HTML. The HTML created depends on properties you set for the controls.

Some of these controls also operate at a much higher level than normal html elements and can be complex, with many sub tags and properties.  Good examples are the Wizard and Login controls. The repeater control also bears mentioning, and there are components with built in logic for things like paging of tabular data.  These all help the developer be more productive.  It's important to remember that you can dictate every aspect of how the HTML for a control will be rendered, though some bits are harder to change than others.  If you want to do enough work you can get the same HTML from a textbox as a gridview, and vice versa.

At this point you may be wondering how the processor knows to use the dll file.  Controls also act as placeholders or anchor points for application logic located in the dll file.   The source code for this logic is not in the .aspx file at all.  Because the application logic is located elsewhere, it is very easy to have a specialized graphic designer build your page layout and a separate programmer build the code.

Code-behind and Events

Now it's getting confusing.  First I said you could use ASP.Net just like PHP or ASP.  Now I'm saying application logic isn't located in the .aspx file.  What's the deal?  Where do you put your source code?  Remember, I said that just because you could use ASP.Net like ASP or PHP doesn't mean that's how ASP.Net is meant to work.  The application logic in an ASP.Net application generally lives in a .vb or .cs file with the same name as the page, called a code-behind file.  The code in this file is capable of replacing almost all the script code that would have been included in your .aspx file.  For most sites, application code in the .aspx file can be limited to databinding expressions or even none at all.

Let me explain how this works.  Some special javascript is included in ASP.Net pages that let the new controls fire 'events', which will cause the page to post back to... itself. When this happens the page is rebuilt (and built from scratch, every time).  The framework knows what event was called, and it is very easy to have application logic that executes only when that event is fired.  More than one event can be processed when a page is built.  For example, the page itself will almost always have a Load event, and several controls may need to process their own version of that event as well.  In addition, you may have a Click event for a button that you need to process.   The source code for these events lives in the code-behind file.

You can do some neat things with the events, like hiding, showing, changing, deleting or adding new controls to the page, saving data to a database, and more.  This all happens at runtime depending on the event, results of a database query, or other factors.  The code-behind file for every page in a Visual Studio Web project, plus any class files in the project, are compiled into a single dll.  Because the code is compiled, it is not necessary to deploy code-behind files to the final site-- only the dll is needed.

Implications

This brings up some things we need to consider.  First of all, we need to setup a new web application in IIS for the ASP.Net processor to be able find the dll file.  Each Visual Studio project needs it's own application.  This can usually be done just by creating a virtual directory.  It is also needed to tell IIS which ASP.Net processor to use (ie, .Net 1.1 vs 2.0) and set the scope for shared/static variables used in the application.

Another consideration is that you'll want to become familiar with Visual Studio.  Visual Studio automatically creates and links your code-behind file, and makes it much easier to create new event handlers.  It also takes care of compiling the dll for you.  It might be possible to get by with only a text editor and the command line compiler, but I doubt anyone does it this way.  Through Intellisense, Visual Studio makes it very easy to find and use items in the .Net Framework you didn't know were there and avoid re-inventing the wheel.  There may be a third party IDE that approximates the functionality Visual Studio provides to ASP.Net, but this is Microsoft's technology.  Expect to get the best results from Microsoft's tool.

You should now have enough information to begin building a site in ASP.Net.  There are a few additional quirks like the page lifecycle and viewstate you'll need to be aware of.  However, I think that understanding this model is the first step to producing good ASP.Net pages.

* By default, code is compiled to MSIL (similar to java's bytecode).  The first time the page is viewed the IL is compiled to native langauge.  You can force your pages to be compiled to native language before the page is ever viewed.

Today is a break from my "Welcome Home" series.  I have several more topics in the works, but none of them have been completely resolved yet.

I've been interested in Linux for about 8 years now.  I still prefer using Windows for various reasons that I've pointed out in the past, but I do try out Linux again every once in a while.  A few months ago I was very interested to hear about noise generated on Dell's new IdeaStorm web site over selling Linux pre-installed, and finally when Dell started selling desktops with Ubuntu.  Since then a lot more noise has been made, and there have been questions whether a Dell with Linux is really cheaper (as you'd expect from not having to pay the "Microsoft Tax").  The latest round has a Linux-based Dell costing $225 more than the equivalent Windows machine.

I think all the hubbub is mis-placed.  Dell, like most other manufacturers, gets kickbacks from some software vendors for including their applications with the machine.  Things like the Google Toolbar or a Norton Anti-virus trial.  If the machine isn't running Windows then it can't include that software.  I've heard unconfirmed rumors that those kickbacks can cumulatively run as high as 80 or 90 dollars.  That's nearly enough to offset the Windows license completely.

In my experience, most people who use linux want to install it themselves.  A pre-configured system isn't going to win many converts just because it's a few dollars cheaper.  If you really want to see open source software on a Dell, ask to them to install Firefox on every machine that goes out the door, at least on the consumer side.  Ask them to include the option to have Open Office on any machine that doesn't come with MS Office pre-loaded.  Or the GIMP (even Paint.Net).  Include Thunderbird alongside Outlook Express.

What happens when millions of consumers buying Dell machines learn they no longer have to pay for MS Office?  When businesses find their employees now come to the table already knowing how to get as much or more out of Open Office than MS Office because they use it at home?  These days Microsoft makes as much or more selling Office as it does selling Windows. 

What happens when millions of consumers buying Dell machines learn that the apps they are used to using are also available on the "cheaper" linux machine, and in fact were developed with Linux in mind first?  You will have a much easier sell convincing them to give Linux a try.  And more importantly, a much better chance they will be satisfied with the experience.

I'm currently using Avast Antivirus on my Windows PC.  I recommend it for several reasons:

• Free for home use.
• Low system resource usage
• Very fast updates, even on dialup
• Boot-time scan happens earlier in the boot process than other virus checkers (Most scanners run after the desktop wallpaper has loaded, in an environment similar to the pre-install environment.  Avast runs in the same step that chkdsk would run).
  
• The first virus scanner of any kind (including MS Onecare) to fully support Vista.

Avast also breaks the old model of a scheduling your virus scans weekly, daily, or however often and instead provides a screen saver adapter that runs a scan in the background when your screen saver kicks in.  It's pretty neat, though I did see a minor display issue with it when using DirectX based screen savers in Vista.  I also think it's a better way to do things.

I may have a good anti-virus scanner, but I'm thinking about dropping virus protection altogether.  I haven't seen a virus alert on any computer I use in well over a year.  This includes my desktop and my wife's laptop (both using Avast, which blares it's virus found messages at you), the work machines provided by my current and former employers (both using Norton corporate editions that tend to bury the notifications in log files), and other machines for which I am the de facto system administrator (close friends and family who are non-technical, most of which now run avast but at least two using Norton consumer).

I can think of several valid reasons for the lack of virus reports:

1. It's is much more common now for virus protection to be run at the ISP level.  There are still viruses out there, but they're caught by your service provider before they ever get to your computer.
2. The process of patching the security flaws used by viruses is more streamlined, and more generic tools like firewalls prevent access to these flaws in the first place.  In other words, it's much easier to keep your computer harder to infect in the first place.
3. Malware is now more often written as Adware or Spyware than as a virus.  For whatever reason traditional security software vendors have decided that Adware/Spyware is out of the scope of their anti-virus tools.  I think it's because they just want us to buy more software from them in the form of a separate spyware scanner or more expensive bundled suite.  It doesn't matter: the point is that while there is much more malware out there than there use to be, there are fewer run of the mill virus out there pointed at your machine.
   
4. What is out there is much, much worse than it used to be.  If you do happen to run afoul of a virus, there's a good chance nothing out there can stop it yet.  I've read about malware that will hide on EEPROM chips on your motherboard, so even a full disk reformat won't get rid of them.  If my anti-virus software can't stop or even see it, why run it?

Now that I've said all that, I will also say that running a pc without virus protection is not for everyone, and I haven't made the switch yet myself.  There's always a chance the equation could change suddenly- the software might improve making it worthwhile or viruses may get worse making the utility more necessary.  I keep my ear pretty low to the ground in the tech industry, so I'm likely to hear about something like that fairly quickly.  But for my family and friends who have likely never even heard of rss or digg I still recommend Avast.

I found this article today.  It's about Microsoft's new Silverlight competitor for Flash. 

According to the article, Silverlight will be made into a full-fledged .Net language. whoopdeedo. What was more interesting was a piece near the bottom where it says (and I quote) "Microsoft will provide a cross-platform version of the .Net framework".

Right now Silverlight is only for Windows and Mac, but I've heard they plan to include linux support later this year. So does this mean all those .Net apps will soon be able to be compiled/released for linux?  Has Hell frozen over?  What's next- Visual Studio for Linux?