February 2004 - Posts
I am looking for information and I am going to ask the community for assistance in this.
- The Garbage Collector in .NET. I have been asking this question on and off for about 3 years and I have never gotten a good answer. It seems that whenever I ask a question about how the GC works in a public forum, the only answer I get is that it is some magical mystical object and I don't need to worry about it. Well, that answer is not good enough for me. I have read posts from Paul Wilson and an article at The Server Side. I want to know more about what is going on behind the scenes, so if you know of any other articles about the GC that are beyond the statement of “it is called when a threshold is reached and it walks a tree of objects and removes the objects that can no longer be reached“ then please send them to me. Why am I interested in this? Well, I just want to know more about what is happening behind the scenes. Black boxes that do auto-magical things make me nervous so I want to know as much as I can about them.
- The CLR integration with Yukon. I know that the CLR integration with Yukon will make the database more stable because there will be less need (if any) to use extended stored procedures. I know that I can now use procedure logic in the database with sprocs, functions, and triggers as oppossed to TSQL's set based logic. I want to know more regarding this integration. What does Yukon's hosting of the CLR do regaring threading, memory management, and other features of the CLR? What are the limitations of hosting the CLR in Yukon?
Please post any type of links in the feedback for this post. Thanks.
Do you know the origin of term BSOD aka “Blue Screen of Death”? Well, the term “Blue Screen of Death” was not the original acronym for BSOD. The original term meant the “Black Screen of Death” and was seen when running under Windows 3.0. A user would attempt to run a DOS application and instead of the DOS application running, the entire screen would turn black with a blinking cursor in the top left hand corner of the screen. The system was hung and would need to be rebooted. So, that is the what, what about the when and the where. The term came from ..........are you ready.........Coca-Cola in Atlanta, GA. Coca-Cola IT was trying to roll out Windows 3.0 within the Global Marketing group. When the users would try and run WordPerfect, sometimes, the user would get the BSOD. This occurred in the summer of 1991. I went out to Novell in 1994, I think, and the Novell developers wanted to meet me because they wanted to know about my boss, a man named Ed Brown. Well, the Novell developers asked me a lot of questions about Ed. I finally asked why, and they said that they wanted to know about the guy that coined the term BSOD. Apparently, he was famous within Novell because he would just scream about the BSOD and nobody at Novell knew what he was talking about for the longest time.....................
Just this week, I was thinking back to the betas of the .NET Framework. One of the things that really stuck out was debugging ASP.NET. I remember finding some problems when debugging ASP.NET applications that were running on a port that was not port 80. After posting some questions regarding this on several lists, I got an email from Shaykat Chaudhuri about the issue and how to work around it in beta2. I remember being amazed at how excited Shaykat was regarding debugging. I was thinking last night back to this and I wondered what had happened to ShayKat. I checked weblogs.asp.net earlier this afternoon and bang, there was an post from ShayKat about debugging in VS.NET 2003. I was floored. I emailed him. He remembered me. I am hopefully going to meet him when I go to the MVP conference in April.
I had always stayed up on the fact that wireless was inherently insecure and that there were some steps that you needed to take to properly secure it, but I never did anything about it. Well, last weekend, I opened up my laptop at home and saw that my neighbor had installed a wireless network. Since I could get into his, I decided that this was a bad thing and I locked my down, finally. I hope that no one has been wardriving through the neighborhood...........................
Now with a day or two to digest what Intel has announced with regards to 64 bit extensions to their 32 bit processors, I wanted to speculate what this will most likely mean regarding CPU's in the world in the next 18 to 24 months
Intel & AMD 32 bit systems. Same as it ever ways. If you are buying them now, you are just going to keep buying them until you need more memory, which is probably within about 18 months for small end enterprise apps, developers, multimedia folks, and power users. For the next 18 to 24 months, 32 bit is fine, but after that you will most likely look to move upwards.
Intel & AMD x86 64 bit systems. Intel's announcement validates what AMD has done with regards to producing a cpu that is an extension of the current 32 bit x86 architecture. Unfortunately for AMD, this will also effectively freeze AMD from getting new customers. If you are already a direct Intel customer and not an existing AMD, why go through the pain and agony of setting up a new infrastructure for AMD parts and the 3rd party chips that are used with them? If you are an AMD and Intel customer, you can now play both sides against each other. I do see AMD driving 64 bit systems into the SOHO desktop and home as seen by recent advertisements. I don't see Intel being able to drive their 64 bit systems into that same space for the next 18 to 24 months due to the fact that they are just starting this ramp up and they are doing it on the Xeon line.
Intel Itanium IA64 family. Like many technologies, until it can be driving into the volume space, and I question the ability of Intel to drive it into that space over the next 24 months, I do not see it as a winner. Assuming I know something about computers when I go to buy a system, I can purchase a 32 bit system that runs what I have today, a 32/64 bit system that can run what I have today and has growth to tomorrow, or I can purchase a system that will not run what I have today but might run what is out there tomorrow. Hmmm, doesn't sound like the right thing to buy to me. Where is Office or the .NET Framework for Win64 when you need it.......... Didn't somebody here once say that the volume CPUs would be the winners? IA64 doesn't look like a volume CPU to me for the next 24 months.
I have kind of put my WebSearch code off on the back burner while I worked on real customer work for the last couple of weeks. Well, I set down this morning and started looking at my data and how things were progressing with about 10 million records. Well, I found an oops, and I think it was a pretty good one. It ends up that I was taking a base url and the script and just plugging them together in a certain case. The result was that I was creating urls like http://www.domainname.com//page.asp instead of http://www.domainname.com/page.asp. Well, I took care of that this morning. I decided to purge my data and start over. I checked my data a couple of times this evening and it appears that everything is running more correct now.
I have made another change to how I am pulling data back from the database in attempt to get around another bottleneck that I am seeing. More info on this after I have a chance to see it when there is more data in the database.
I got the following response from Jerry Pisk regarding my post about MS Developer Support and that got me thinking why I am developing on the MS platforms:
re: MS Developer Support
So a bug known for almost 6 months is not documented (let alone fixed)? You
consider that good support? As for Linux (and open source development in
general) - I personally ran into several issues with the tools I've been using
and once I had to write a fix (which eventually got included in the main code)
and every single other time somebody else already wrote a patch, since people
can actually do that - fix things that bug them. Unlike all the problems with
Vs.Net and .Net framework in general where nobody fixes anything (developers
don't because they can't and Microsoft obviously has its own reasons).
This is my whole problem with the Linux development paradigm. “If you find a problem, you can fix it” is there way of thinking. Well, that's great if you are building a solution that plugs into the Linux kernel or does something fairly deep in the system. I applaud that. I really think that is a great way to get things done for those developers that need access to kernel level code. However, my customers are paying me to solve their business problems. Typically, this involves writing code to automate business processes. My customers do not want to pay me to “fix” someone's Linux tool or fix a problem in the kernel. While at one point in my career, I would have truly enjoyed working in the Linux Kernel and doing C++ types of stuff (BTW, I used to do C/C++ programming and I was very good at pointers and pointer arithmetic), that day is no more. I prefer to work with these higher level environments because that is what paying customers want from me. They want code to solve their business problems yesterday. By working with MS's tools, I have a higher level of productivity that some pieced together environment. Is Linux bad? No. However, at this time, Linux is not the tool for me and it is not a tool that my customers are paying me to work with at this time.
Regarding Jerrry's statement about the issue having been around for 6 months. Well, that's not accurate either. The issue was around for about 2 months, when I called about it. I had a work around that evening with an updated comsvcs.dll a couple of days later that resolved the problem. I was pleased with the support I got from MS on that issue.
Given some of the things that have been said by Roy and Alex, I wanted to chime in regarding a very recent development support experience. I was having a problem with debugging a set of VB6 components running under COM+ on Windows 2003. I had searched with google. I searched the MS knowledge base. I searched newsgroups and I never found anything that was helpful. I finally broke down and called MS Developer Support at the begining of December. It ended up that the problem was a bug that had been discovered in September, 2003. I was the second person to report the bug. While MS did not have a full fix for the comsvcs.dll file at that time, the person I worked with (Lalitha Gomathinayagam) was able to provide me a work-around. While working through this, she also assisted me with a similar problem in debugging those objects within Terminal Server on Windows 2000. FYI, we never could get it to work, but she was helpful and provided me with continual assistance way beyond what I would have considered as necessary. The bottom line is that she went out of the way to help and I fully appreciate it.
This is interesting to me because I have often tried to do some development on Linux. Each time I get into some problem, I find no one in the Linux community is able to help. Do I think that the Linux development community is somehow bad? No, they are not. They are just no intune with what developers need. They are two busy building the platform to talk with the folks trying to build solutions on their platform. MS seems to have it closer to right in my book.
More Posts Next page »