Is time linear?
Does every interval of time contain the same amount of information?
What does time contain anyway?

Time is a container for change. Time contains the delta between one state of the cosmos and another. Each finite interval of time contains within it the amount of change that has occurred from the beginning of that interval to the end of that interval.

In a sense, change is novelty and novelty is change. Novelty is merely a synonym for change. So when we think about novelty theory, to refer back to the work of Terence McKenna, we're really analyzing the content of time.

We know that the content of space is matter, and energy. But what is the content of time? It's a perplexing question for those who cannot see the logical conclusion that time in fact contains information. For it is information that informs change. Information is nothing other than change, and change is information. Novelty is therefore information. We're running around in circles describing the same phenomenon with different words, each word trying to out-grandiose the others.

But the fact is simple and yet stunning: Time contains information, much like how space contains matter.

Now, we know another interesting fact from basic observation of the world around us, and that is that information is cumulative. You never lose information. This has been elaborated by Terence McKenna as well. Essentially, the fabric of time itself is cumulative. At every stage in the evolution of the universe, we have gone from a state of low complexity to a state of higher complexity. We've never "devolved" into a state of lower complexity. Complexity has always increased.

Well, what is complexity? First, it helps to understand how we obtain complexity. At the start of our universe, if we accept the big bang theory, the highest level of complexity in the universe was characterized by a primordial soup of electrons and elementary particles. From that evolved the first atom, clearly a structure with an order far more advanced than what had existed prior to its emergence out of the primordial ontos.

Now, this first atom, the hydrogen atom, contained a whole lot more information than its parts, or even the sum of its parts. Because the hydrogen atom has a logical structure far more elaborate than the logical structure which represents an electron. Indeed, it is this logical structure that we must talk about when we're talking about complexity and information. The hydrogen atom is an entity which requires far more information to describe than the electron or the proton alone. So basically, the primordial soup required a very small amount of meta-data (meta-information, or logical structure) to describe, compared to what followed (i.e. the hydrogen atom). This is where we get the notion of increasing complexity. Complexity is the measure of the quantity of information required to produce the simplest possible explanation of a particular physical phenomenon.

As the universe evolved further, we got more and more complex structures. We got other atoms, molecules, organic compounds, and then biological life, and finally social life; intelligent life. Each of these complexities builds on the previous level of complexity. Molecules build on atoms. Social life (cultural or intelligent life) builds on acultural, biological life. Microbial life builds on essential organic compounds. In essence, each new level of complexity contains within it all existing levels of complexity.

Thus, complexity is conserved. We can in fact emphatically state that complexity is never destroyed. It is strictly conserved.

So what does this all imply for the nature of time? Well, time contains within it descriptions of changes within entities of varying complexity. At the beginning of the universe, each second of time contained a only a very minute description of changes, because only a minute description was needed for the level of complexity at which the universe had arrived at that time. Basically, God only needed a handful of bits of information to describe a change in the state of the universe when the universe was still in its primordial soup state.

As the universe complexified, necessarily the amount of information contained within each second of time needed to increase, in order to completely describe the more complex universe that was emerging. Basically, each level of complexity required more information about the changes within that level of complexity.

Thus, as the universe cooled and complexified, time became more and more burdened with information, so that each moment of passing time contained within it more information than the previous moment.

This process continued to this day. With every passing moment, time "expands" to contain more information than any previous moment that has ever existed. This is a profound concept to grasp, with profound consequences for our perception of time. It means that our linear time assumption, the assumption that time is isotropic and linear - that each moment is the same as every other moment, and that each interval of time is qualitatively and quantitatively the same as every other interval - is absolutely patently false and misleading.

We have to ditch the idea that time is somehow plain, linear, and uninteresting. Time is extremely interesting, and ought to be studied by science like nothing else, because we don't have a sufficiently clear understanding of the nature of time.

But the interesting implications of this "expanding time" theory are many. This theory actually validates intuitively-derived beliefs in many cultures that time is accelerating, or that time is heading towards an ultimate end. In fact, even modern science has managed to create a theory mainly involving human culture and cultural progress which indicates that there may be a point in the not too distant future where all of our knowledge, having been preserved thanks to the law of conservation of complexity, leads to a point of infinite temporal acceleration - a point of asymptotic discovery and asymptotic change, putting an end to time itself. Indeed, this very idea has been prophesied by others, including the ancient Mayans with their apocalyptic 2012 prophecy, or the Christians, or even modern-day prophets like Terence McKenna, although I'm sure he would despise being called a "prophet."

We must challenge all of our dearly-held assumptions about time or else we will not proceed to make true scientific discoveries. Today, we carry notions about time that are akin to believing that the Earth is flat or that it sits atop the backs of four turtles. For example, we believe that causal connections can only exist from the past to the future. We have established one predetermined direction for causality. Yet, we can clearly observe retrocausal effects all around us that seem to defy the laws of physics and all too often get classed as mere coincidences or worse, paranormal phenomena. In fact, such occurrences should be observed experimentally and we should try to develop a theory for explaining such retrocausal phenomena as the appearance of 9-11 as a motif in various artifacts well in advance of the actual event which occurred on 9-11-2001. Other retrocausal phenomena include such cases as the flight of animals to safety prior to a devastating tsunami or earthquake. Anything that is often classed as premonition or prophecy ought to be investigated as a potential candidate for retrocausality - events from the future having causal links to events in the past. It's crazy to think that the future could have a causal influence on the past, as it means that the past is now just as malleable or perhaps more malleable than the future!

Anyway, I hope I've been able to shed some light on the strange nature of time and why what we humans often think is obvious is really not so.

I could probably talk further here but instead I think I need to actually summarize what I described:

1. Time is a container for... change in information, also known as novelty. Necessarily, then, time has at least two dimensions.
2. Complexity is conserved. Each new level of complexity builds on lower levels. Complexity is never destroyed or reduced.
   
3. Time is non-linear and quite probably anisotropic.
4. Time is expanding, with each one-second interval containing more information than any previous one-second interval. This is subjectively perceived as an acceleration.
   
5. There may be an endpoint for time, consisting of an asymptotic acceleration of the rate of progress toward infinite complexity.
6. Causality probably works both ways, even if it seems odd to us. Retrocausality seems to explain perfectly the phenomenon of prescience in some organisms.

Bend your mind, but be careful not to break it!

Spring Solstice

‘Tis the season to be jolly, as the sun begins to dawn.
Spring hath right now just begun.

The solstice ends the sun’s decline.
Soon the snow will melt, the sun will shine.

The sun will burn, high in the sky...
Just like your love did, last July.

Dan's Gold & Silver Recommendation: Buy (with caution)

---

We've now corrected 10% in both gold and silver, from the top reached a few weeks ago.

I think it's time, given the speed and severity of the correction, to start buying again.

However, I do think that further downside is possible. So cautious buying is advised.

---

I will try to have this segment at every major turn in the market so that you can stay up to date with the latest market movements.

So stay tuned for more of "Dan's Gold & Silver Alert."

Internet Explorer 9 will be coming out soon. It is going to have hardware-accelerated rendering of web pages. In essence, it will use the video card (instead of the CPU) to render web pages. This means much faster performance, awesome effects (even 3D), and less CPU usage.

Channel 9 has posted a demo of IE 9. The video shows some of the awesomeness of this new version of IE.

So here are some highlights of what's coming:

1. Web page rendering on the GPU (instead of CPU)
2. Better standards support
3. New JavaScript engine, with performance similar to Firefox

Here is a comparison of browser performance, from Ars Technica:

As you can see, IE 9 is now on par with Firefox and Chrome.

Not good news for Firefox. Or is it?

It seems the Firefox people aren't sitting idly by. They're busy implementing hardware accelerated rendering in Firefox 3.7.

So it's certainly going to be an interesting competition between IE and Firefox. It looks like the browser wars are on again.

Not long after I posted my first topic outlining the idea of Windows 7 smart phones, I found this...

Razorfone: A Conceptual Windows 7 & WPF-powered Multi-Touch Phone Retail Experience

It looks like the idea of a Windows 7 phone is alive & well. While the "Razorfone" is a concept for retail environments (a kind of kiosk), it's nice to see others considering the idea of putting Windows 7 on phones.

One more piece of good news on the mobile phone front:

WIND Mobile Takes Off - National Post

WIND Mobile - www.windmobile.ca - has finally been given the green light in Canada. No longer will we be limited to the triopoly of Rogers/Bell/Telus. Hopefully, this means no more 3-year contracts and lower prices in general. Canada is the most backward country in the world when it comes to mobile phones, largely because of Rogers & Bell's huge political influence.

I urge all who are upset about Rogers or Bell to check out WIND Mobile and consider switching over. Actually, I urge all to check out WIND Mobile. From what I can see, their plans are quite cheap and straightforward.

1. How much memory does 32-bit Windows support?

I'll try to explain this as simply as I possibly can...

You can have as much as 64 GB of RAM with 32-bit Windows, but there will be a hole between 3 GB and 4 GB.

64 GB? Yes. How is that possible? Well, Intel processors for a long time have had a feature called PAE (Physical Address Extension) that adds another 4 bits to the 32-bit limit of Windows, making it effectively 36 bit.

But...
A few caveats:
- If you have only 4 GB of RAM, you'll see just 3 GB because of the hole between 3 GB and 4 GB.

- If your CPU doesn't have PAE, you're stuck with 3 GB as the limit. Go to My Computer - Properties (in XP) to verify you have "Physical Address Extension" listed in your system information.

Also, processes in 32-bit Windows will see 2 GB of memory. But they won't see the same 2 GB. They'll be moved around by Windows so that all of your memory gets used (it's called multitasking!). So there is no "2 GB limit" as some might have you believe. The real limit is 3 GB, or even more if you have PAE.

2. What is different in 64-bit Windows?

The first thing that's different, you can access up to 16 EB (exabytes) of RAM! That's 8 million 2-TB hard drives!

But there are a few more things you need to be aware of:
- 64-bit Windows uses up 60% more memory and disk space than 32-bit Windows due to the doubling of pointer size
- You may have trouble finding 64-bit drivers for older hardware
- 32-bit software will still run perfectly on 64-bit Windows, thanks to WoW (Windows on Windows) emulation
- 64-bit Windows allows you to access all 4 GB of memory when you have 4 GB installed (not just 3 GB like 32-bit Windows)
- There is no memory hole in 64-bit Windows
- Each process can use more than 2 GB of memory
- Some CPU-intensive operations will complete faster if they take advantage of 64 bits (up to 5 times faster!)

Overall, if you have 4 GB of RAM or more, you should install 64-bit Windows to get rid of the memory hole. If you have 3 GB or less, you should stick with 32-bit Windows, because 64-bit Windows will eat up 60% more of your precious RAM.

My Experience - Going from 2 GB to 4 GB

I'm running 64-bit Windows 7 on my machine, with 4 GB RAM. It runs much more smoothly than it did on 2 GB of RAM. I installed 64-bit Windows 7 on 2 GB of RAM. Don't do it. It caused my memory usage to go up from 50% to 80%. Now, with 4 GB, my memory usage is down to 40%.

So, if you have 3 GB or less RAM and aren't planning to upgrade it right away after installing 64-bit Windows, don't install 64-bit Windows. It will eat up too much of your RAM.

Today I just discovered a neat little WPF graphing library called D3 (DynamicDataDisplay).

It's amazingly architected so that it's fast and extensible. Although it requires .NET 3.5, I was able to downgrade it to .NET 3.0 by using LinqBridge, a free library that emulates 99% of Linq without requiring .NET 3.5.

Actually, LinqBridge deserves a topic on its own - there is literally no reason for you to require .NET 3.5 in your apps, unless you use Linq-to-SQL. Linq-to-Objects is 99% emulated by LinqBridge.

To .NET library developers: start distributing .NET 3.0 versions of your libraries using LinqBridge, so that my Vista users don't have to download .NET 3.5. Saves me a boatload of headache as an ISV.

So, back to the main topic. If you're looking for a WPF line plot library that's free or simply want an example of how to build a WPF control library the right way, just take a look at D3.

Those are my findings for today. I guess it's been an exciting day!

So, it seems Moore's Law is at it again. And those who are not aware of it (by now) will be left in the dust. Read this article and you'll know what I mean.

First, I must warn you that you may be offended by reading this article. If you are an ardent fan of Google or Apple and/or a hater of Microsoft, you may not like what I'm about to tell you. That's fine. Just be prepared, if you do plan to read on.

Yesterday I installed Windows 7 on a 5-year-old laptop with 512 MB RAM and only 7 GB of free disk space. It installed (surprise!) and ran flawlessly! It even ran smoother than the XP installation I had on it before. Probably because with all the service packs, XP has actually become more bloated than Windows 7.

Now, I want you to note the specs: 512 MB RAM, 7 GB of disk space. Impressive. A high-end PC from 10 years ago would've had these specs. So literally, Windows 7 supports a decade of computers!

But what's more fascinating is the mobile arena. Currently, Apple is still dominant and yet still afraid to lose its iron grip on the iPhone. On the surface, Apple appears to be very friendly to developers, but behind the scenes they are the control freaks they've always been - I'm looking at you, Steve!

Anyway, there are quite a few frustrating things about the iPhone. First, you can only sell your app through Apple's app store and it has to be approved by Apple. Second, there is no Flash on the iPhone, and no web browser other than Safari. This ought to raise eyebrows and even get Apple into legal trouble like Microsoft got into trouble with IE and Windows, for supposedly abusing their monopoly. But it seems only Microsoft is the unlucky one.

Next we have Google's Android OS, which is a commendable OS. It has everything. It is, for mobile devices, like Windows is for PCs. It is open to developers and developers can share & sell their applications without Google's approval. The only "problem" with Android is that there are too many variants of it. I wouldn't really call this a problem. It's a natural drawback of having to support a wide variety of devices. I mean, look at Windows: Windows XP, Windows Vista, Windows 7, and do you hear Windows developers complaining about it? No. They've adapted to it. They expect it. Only Apple fanboys complain about "too many variants" of Android because they don't understand it.

Next, we have Windows Mobile. Or do we? Windows Mobile is laughably dated and limited. Microsoft seems to have lost it completely on the mobile front. But have they? Or are we all missing something that's actually staring us in the face? Are we missing the elephant in the room?

Yes.

Let me introduce you all to the elephant in the room. It's Windows 7. Yup. And it's moving to smart phones. Remember, I installed Windows 7 on a PC with 512 MB RAM and 7 GB of disk space. Why do you think Microsoft decided to actually support old devices this time, and not raise hardware requirements like before? Why do you think Microsoft developed multi-touch capabilities in Windows 7? Is it for all those giant useless tablets out there? Is it for all the giant useless netbooks out there? No! It's for MOBILE PHONES!

Suddenly it all makes sense. But wait, I hear you say, how can Windows 7 ever fit on a phone? Simple: There are smart phones today that have 512 MB of memory. There are smart phones today that are extensible (via microSD card) to as much as 32 GB of storage. Last but not least, is Intel's Atom processor. It's an x86 processor (just like the desktop ones) with speeds of nearly 2 GHz! But the best thing about Atom is, it's extremely low-power and low-heat.

So the situation is now ripe for Windows 7 to start transitioning onto smaller and smaller mobile devices. There are MIDs / UMPCs currently available with screens of 4.8" which is about as small as a PSP. They fit in your pocket. And they run Windows 7. The leap from here to mobile phones is tiny. There is no leap. It's a baby step.

In conclusion, if you thought Microsoft lost the mobile space, you are totally mistaken, and you'll be in for a shock next year. All the Android and Apple fans out there won't know what hit them. Better get on for the ride.

As for what I'm doing to prepare, I'm back developing client-side Windows applications. I use WPF and .NET. They are extremely easy and fun to work with. Microsoft has always had the best support for developers, which is what helped them gain (and maintain) a monopoly for so long. Windows has more software than any other OS, and will continue to do so for many years thanks to Windows 7.

Apparently some of my older blog articles were really quite popular, because today I stumbled upon something I wrote 5 years ago:

Application.DoEvents() - The call of the devil.

DoEvents messes up the normal flow of your application. If I recall correctly, DoEvents is asynchronous which means it terminates before the application has actually processed any outstanding events, so if you're using it in a procedure with many sequential statements, calling DoEvents causes a huge disturbance whenever it's called. Basically, if you find yourself needing to call DoEvents anywhere, think about starting another thread instead, or using asynchronous delegates.

Imagine this if you will: You have a button on your form that, when clicked, does some complex processing. During the complex processing it also intermittently calls DoEvents to keep the application's user interface "responsive" -- not the best method, I would have used async delegates, but we're talking about a mediocre programmer here. Anyhow, the user sees the application still responding and no indication that there's some processing going on. So the user clicks that button again WHILE the processing is going on! The button responds to the event and starts another processing thread but it isn't actually a thread here, I hope you get what I'm saying. So, like I said earlier, DoEvents screws up the flow of the application too easily.

I want to comment on this further, because I don't think I was really clear at the time.

DoEvents really is evil. Horribly, horribly evil.

In fact, the whole Windows Forms threading model is deficient. The fact that you can set a Label's Text property from any thread is a clear warning sign that something is wrong. This is only now becoming evident to me after having worked for a few months with WPF, which doesn't allow any such nonsense. It will throw an exception if you try to execute UI code on a non-UI thread.

DoEvents should have never been included in the .NET Framework, because it gives a programmer the illusion that you can get by without worker threads. You can't. If a programmer wants to keep the UI responsive while another task is executing, that programmer should use a background worker thread. To update the UI from that thread (to show changing progress), the programmer should call Invoke on the appropriate control and pass in a delegate that will be executed on that control's UI thread. Not only does this serve to keep things consistent, but it also reduces the chances of odd bugs related to threading (which are always difficult to troubleshoot).

So, in short, avoid DoEvents and do what good programmers do: use worker threads. WPF makes it easy (and dare I say fun?) to create & use worker threads, and it's perfectly safe. Windows Forms has a somewhat sketchy UI threading model, mainly because it still has to deal with Win32 API behind the scenes. This is also a reason why you should migrate to WPF and stop releasing production software built with Windows Forms. The sooner Windows Forms dies, the better.

So today will be the last time I use System.Diagnostics.Process.Start without explicitly setting UseShellExecute to true.

Why?

Oh, it started out innocently enough - I was building a simple load testing tool in C# to load-test a custom ASP.NET HTTP handler I was implementing. The tool would basically run wget many times to simulate HTTP requests. Don't know why I didn't just use System.Net.WebClient (because I certainly could've), but I guess I just had wget on my mind.

Anyway, so the tool ran fine but it slowly leaked away memory and handles. Initially I thought it was my HTTP handler. So I ran it with an invalid URL, just to test if maybe the load testing tool itself had a memory leak. Sure enough, it did!

The leak seemed to be coming from my call to System.Diagnostics.Process.Start.

So I did a quick Googling and it turns out that System.Diagnostics.Process.Start causes the child process to inherit handles from the parent process. That means, whatever process you spawn (e.g. Internet Explorer), that process gets all of the handles owned by your process! So even if you free up handles in your process, if the process you spawned is still running, your handles won't really be freed because the child process is supposedly using them. A more detailed explanation can be found here.

As it turns out, the CreateProcess call in System.Diagnostics.Process.Start has a certain parameter that is hard-coded: the bInheritHandles parameter is hard-coded to true. Well, that's a shame now isn't it?

So what can we do instead?

I would prefer any solution except calling the CreateProcess API directly, since API calls are ugly. One option is to set ProcessStartInfo.UseShellExecute to true before calling Process.Start. However, you won't be able to redirect stdio. In fact, if you want to redirect stdio you either have to accept MS's buggy implementation or roll your own with pipes, API, and all that funky stuff.

One last thing...

With the Process class, be sure to explicitly Close the process object (not just Dispose) after starting the process or after you're done using it, because otherwise the process handle may leak.