Emacs is definetly difficult enough to qualify as a life long challenge. Emacs is like 42 in Hitchikers Guide to the Galaxy. Don't get me wrong, xemacs is my portal to the world. But, my configurations and modules are as cryptic as the Knights Templar. I've forgotten how half of them work anymore. Emacs is like Darth Vader. One day you realize that you are mostly Lisp/Emacs, but your not sure how you got there. You know its somehow evil, but the power of the darkside is just too tempting to ever go back.
Look, I love Lisp, and with it I can get my emacs to do wonderful things. However, there is a major drawback to using a relatively obscure language for mainstream application development. Fewer third party libraries will be available in Lisp. This means that you'll have to do a great deal of work from scratch either porting, patching or layering libs into your lisp framework. Let's face it. Also, your code will potentially suffer from interoperability problems unless you are extremely careful.
Support really varies with the product. 15k support contracts for enterprise software are very different from consumer tech support. In the area of consumer tech support, I think things have actually gotten much better. I was shocked the other day, when I had to call dell's tech support and immediately got a rep. The same thing even happened with my ISP which usually runs 1 hour hold times. With expensive software, tech support often is ok, but pricey. Also, often it is unessessary. If they would just give me the source code, I wouldnt ever have to bother Microsoft for anything. Strange, that I never find myself calling up Linus for tech support.
Shave off all of your hair, and go aquire a Nazi SS uniform. Go into your manager's office and demand a pay raise. Threaten him if nessessary. You may want to bring a firearm in case in order to better handle a potential situtation.
Clearly one could ultimately retrieve the data, bit for bit, either by capturing pixels in the application, window manager, OS, or even hardware layers. However, such measures could make the copying task difficult and time consuming and such an effort would involve significant manual or engineered effort. This is the key to the copyright problem introduced with our digital age. Magazine publishers were not terrified of printing presses or even xerox machines. It is the ease of cut, paste, copy, and link that gives them the chills. I may pay for a magazine instead of reading a xeroxed one, and I might pay for the real picture as opposed to a reproduction.
Summary: COM+ and Windows 2000 Server provide an intricate infrastructure for building distributed applications. This article identifies and explains the key technologies and services you'll need to master in order to build large-scale information systems for Windows 2000 Server. (22 printed pages)
Adapted from chapter one of Programming Distributed Applications with COM+ and Microsoft Visual Basic 6.0 (2nd edition Microsoft Press ISBN# 1-57231-961-5)
So, one millennium's ended and another's just begun. Just how much impact did the changeover have on your life as a professional developer? Sure, when the clocks all ticked zero, there were a few hiccups here and there. A few outdated systems had to be taken to their final resting place. But our industry as a whole didn't experience the doomsday scenarios predicted in the media. This was especially true for those of us who build applications based on operating systems and development tools created within the last decade. It's pretty humorous when you look back on it all. Rumors of the death of your company's information system were obviously greatly exaggerated.
Then again, does the press really ever know what's going on in our industry? They missed the fact that it was a century bug and not really a millennium bug. The problem was rooted in the use of two-character dates instead of four-character dates. If the human race had had the same technology 100 years earlier, we would have faced all the same issues on New Year's Eve of 1899. However, "millennium bug" sounded so much more sensational and, consequently, sold more newspapers and magazines.
Remember a few years back when the press predicted that everything would be rewritten in Java, including the United States Constitution and the Magna Carta? Now the Java buzz has subsided and we see Java for what it is--a young and promising language with its share of strengths and weaknesses. It didn't take the industry by storm. It's a language that's usable in some situations but unsuitable in others.
Now everybody's talking about XML as the cure-all technology. I know that as XML matures, we'll find more and more uses for it. It will solve lots of problems that are very hard and very real. But XML will never replace technologies such as COM, Corba, and Java, as many people have suggested. It's important that we keep all these new technologies in perspective. It's not healthy to get overly excited about a technology that might solve all your problems a few years down the road when you have to ship an application in the next few months.
Why Should You Use COM+?
I'll assume that you are at least considering using COM+ to build distributed applications. Many companies are using COM+ and Microsoft Windows® 2000 because they provide a robust development platform. This platform is made up of several core technologies that provide the basic building blocks for constructing multitier business applications. And, after all, the more the underlying platform brings to the table, the less code you have to write and debug.
I probably don't need to convince you that multitier applications offer many advantages over the two-tier applications that were in vogue in the late 1980s and early 1990s. Your company has probably already decided to abandon the two-tier approach in favor of a multitier strategy. However, I'd like to take a little time at the beginning of this article to review the most significant problems with two-tier applications and explain how multitier applications provide solutions to many of these problems. I'll also discuss why multitier development introduces some new problems and additional complexities.
One of Microsoft's goals in developing COM+ has been to offer companies the benefits of multitier applications while hiding as much of the inherent complexity as possible. Over the last decade, Microsoft has made many advances in creating this infrastructure for distributed applications.
The first version of COM shipped in 1993. Since that time, COM has grown from a young and complicated technology into the core of Microsoft's multitier strategy. This article examines COM's most important milestones. Along the way, I'll also do my best to define all the acronyms that those marketing folks have generated over the years. You've probably heard of OLE, DCOM, ActiveX®, and MTS. COM+ and DNA are the two most recent additions to the list. But have you ever tried to explain the difference between these terms to someone at a cocktail party? It's not easy, is it? They all mean different things to different people.
The article concludes with a high-level overview of the distributed services that have been integrated into the COM+ platform. Any nontrivial multitier application requires such things as transaction support, integrated security, a Web server, messaging, and delivery of event notifications. This article will identify where each of these COM+ services fits in. This should give you an appreciation for COM+ as a whole and show you the light at the end of the tunnel.
From Two-Tier to Multitier Systems
One of the best reasons to use COM+ is to move a company's information systems from a two-tier architecture to a multitier architecture. This transition requires the design and creation of a middle-tier layer of business objects. Business objects usually sit between client applications and database servers. COM+ serves as the platform for these types of systems.
Two-tier systems have been widely deployed in the industry, so the problems associated with them are well known. Let's review the key shortcomings of a traditional two-tier architecture, such as the one shown in Figure 1.
The station runs on VBScripts running in MTS talking to an Access database. Complex vector analysis computations are done in Excel. Commications with station are via IM and IIS. The station arm talks to the rest of the station via DCOM.
All in all, the computer system is extremely robust, and expected to last for 25 years with only the occassional microsoft patch.
The regional bells only have dominance for one reason. DSL like any utility requiring infrastructure is a regional game. Covad and the late NorthPoint attempted to national with their service. That's like starting a nation-wide plumming service. While these large DSL providers are struggling, the smaller, local DSL providers are having a boom time. Nobody likes the phone company. Nobody wants to work for the phone company either. This in the end will give the smaller regional DSL providers a competative advantage over the bells. They will be able to provide infinitely better service than the phone company will ever be able to. However, trying to scale such a service to a national (or international) level will dismantel that strategic advantage.
Hemos is off his rocker. IBM could care less about MySQL, and Postgres. IBM is pitched in a battle with Sun in the enterprize server market. The database machine is often the big piece of hardware that enterprize sites buy, and it dictates the type of storage array and software they'll use. Sun + Oracle has a nice ring to it when you are talking about laying down $40,000+ for a database. That's were IBM and Informix come it. With a top of the line Database (I'm not sure what is wrong with DB/2), IBM can compete with Oracle, which really means that they can compete with Sun.
It is a tough call, but in the generic platform enviroment of Linux, I think jiffies have to go the way of the 5" floppy. The overhead for refined timers is quite expensive, however it probably could be eliminated with some hardware specialization.
Of course HZ is the number of timer interupts per second.
1024 is the propper setting for an Alpha chip. If you are running an alpha, this may be why your performance has increased. However, it appears your are running x86, in which case you should probably not set the HZ to 1000. The increased interupts will greatly reduce the performance of User mode applications, given that the kernel will run more frequently. Basically, your CPU had better scream in order to run with a 1 millisecond tic (1000HR). If your are running some screaming P3 or P4, the 1024 setting might not be a bad idea, but I may be fudding that fact.
The crc is only 1 byte and can be defined as the crc of this block and the previous crc. The decompressor then chops through the data, when a crc comes up incorrect, it goes back and chooses a different possible value for a proceeding crc until the entire series of datablocks validates.
Aside for not clarifying the use of external dictionaries as being illegal (Mike let Patrick use the filesystem filenames to store data), Mike also didn't clarify processing time. If processing time is not a factor, you can create reverse CRC/Checksum compression that is acurate almost everytime. Reverse-crc compression is accurate inversely porportionate to the rate of compression. So, you simply need to choose an large data block (1 gig or so) to compress with a very low rate of compression, say 1000/999 or something like that. Then you let the reverse crc decompressor work on it for a few days, and eventually you'll come up with the right data 999/1000 times.
One solution however impractical an imperfect is to reverse-checksums. Essentially, you take the data block and perform a series of running checksums (like CRCs). You store only the checksums in the "compressed" file plus tidbits of "hint" real data. What you have is a lossy form of compression. However, with enough processing power (a few dozen E10,000s) you can reverse calcuate the checksums which will give you accurate results with 99.999+% of data blocks (some data blocks will return false solutions). It is simply a matter of home much processing time you are willing to throw at the problem.
Clearly, this is the crux of the arguement, and intellegent people can waiver here. In a sense the fragments were compressed in that the 5's were chopped off. I would actually argue that this is a form of compression, however impractical in this case. For example, if you create a dictionary of "phrases" and install the dictionary within the decompressing client, and send the "compressed" files you are really doing the same thing that Patrick did. The difference, is that Patrick exploited the filesystem to store his dictionary data, as opposed to actually putting the dictionary inside the decompressor. In fact what he did IS compression, and the files were compressed in size. Patrick could have done even more devious techniques by moving all of the data into the filenames themselves. Because Mike did not spesify that external linkage to datasources was illegal, what Patrick did in my view was within the confines of the contest.
Thats the question that I have. This makes no sense. DB/2 has the same distribution that Informix has, are they going to support both? I suppose that DB/2 is more of a mainframe application than Informix is, but I could be fudding that.
Patrick I meant can I send you a compressor and several compressed files whose total file size is less than the original uncompressed file and from which I can regenerate the original uncompressed file
Mike Sure.
Pay up Mike. Pay up. You were too careless to plan out the rules and think about your intent before you threw 5k into the sink. Cough up the cash or loose all honor.
At first, when I was reading the page, I felt that Patrick clearly cheated, given that he exploited the filesystem to store data. However, after reading your comment, I must agree. Mike should have clarified the rules. Clearly, Patrick deserves the cash.
First of all, the decompressor was aloud to be written in shell scripts. There are all sorts of hacks one could do if you are able to link to other code for your decompressor. It should have have to have been written in C, and should have have to have relied on stdin.
Yes, mdev 7.0 is probably one of the most compliant C++ compilers out there. It is one of the few linkers than handles template-objectfile redundancy propperly without tedious pragma's and bizzare typedefs in cpp files. Also, the msdev implementation of STL and IOStreams is to the letter of the standard with full template iostreams (unlike g++ non-template IOStreams). However, msdev's implementation includes nothing that is not in the standard (like hashtables), except auto_ptr. All in all, Microsoft has embraced C++ big time (MFC and especially ATL). Frankly their devotion to that sad ancient religion, hasn't helped them conjour up the stolen data plans nor given them clairvoyance enough to learn the location of the rebels hidden fort...kha..cc.cka..aaak.
I would hope that any changes to the standard will focus on the C++ Standard Lib and not so much on language semmantics/features. The C++ library is in need of some serious features. While I recognize why they had to stop and finish, the work is losing ground to more complete libraries in other languages. The STL needs to be completed, and dare I say, some of the implementation should even be standardized. Certainly, the interfaces should be standardized. My God, lets make hash tables official, and pick an implementation. Also, the iostream libs need to be expanded to include asynchronous I/O, more usable streambuffers etc. Also, the standard needs to officially ditch strstream and replace it with string_stream. As for threading, well Posix has pretty good threads, although events could be wrapped up a bit neater (like dare I say in win32). As for handles and such, it would be in the C spirit, as the standard C lib has things like FILE and such.
Slashdot Mirror
There are 2 awesome books on kernel and driver development from our friends at O'Reilly.
Understanding the Linux Kernel
and
Linux Device Drivers
Emacs is definetly difficult enough to qualify as a life long challenge. Emacs is like 42 in Hitchikers Guide to the Galaxy. Don't get me wrong, xemacs is my portal to the world. But, my configurations and modules are as cryptic as the Knights Templar. I've forgotten how half of them work anymore. Emacs is like Darth Vader. One day you realize that you are mostly Lisp/Emacs, but your not sure how you got there. You know its somehow evil, but the power of the darkside is just too tempting to ever go back.
Look, I love Lisp, and with it I can get my emacs to do wonderful things. However, there is a major drawback to using a relatively obscure language for mainstream application development. Fewer third party libraries will be available in Lisp. This means that you'll have to do a great deal of work from scratch either porting, patching or layering libs into your lisp framework. Let's face it. Also, your code will potentially suffer from interoperability problems unless you are extremely careful.
Support really varies with the product. 15k support contracts for enterprise software are very different from consumer tech support. In the area of consumer tech support, I think things have actually gotten much better. I was shocked the other day, when I had to call dell's tech support and immediately got a rep. The same thing even happened with my ISP which usually runs 1 hour hold times. With expensive software, tech support often is ok, but pricey. Also, often it is unessessary. If they would just give me the source code, I wouldnt ever have to bother Microsoft for anything. Strange, that I never find myself calling up Linus for tech support.
Much better advice:
Shave off all of your hair, and go aquire a Nazi SS uniform. Go into your manager's office and demand a pay raise. Threaten him if nessessary. You may want to bring a firearm in case in order to better handle a potential situtation.
Clearly one could ultimately retrieve the data, bit for bit, either by capturing pixels in the application, window manager, OS, or even hardware layers. However, such measures could make the copying task difficult and time consuming and such an effort would involve significant manual or engineered effort. This is the key to the copyright problem introduced with our digital age. Magazine publishers were not terrified of printing presses or even xerox machines. It is the ease of cut, paste, copy, and link that gives them the chills. I may pay for a magazine instead of reading a xeroxed one, and I might pay for the real picture as opposed to a reproduction.
Summary: COM+ and Windows 2000 Server provide an intricate infrastructure for building distributed applications. This article identifies and explains the key technologies and services you'll need to master in order to build large-scale information systems for Windows 2000 Server. (22 printed pages)
Adapted from chapter one of Programming Distributed Applications with COM+ and Microsoft Visual Basic 6.0 (2nd edition Microsoft Press ISBN# 1-57231-961-5)
So, one millennium's ended and another's just begun. Just how much impact did the changeover have on your life as a professional developer? Sure, when the clocks all ticked zero, there were a few hiccups here and there. A few outdated systems had to be taken to their final resting place. But our industry as a whole didn't experience the doomsday scenarios predicted in the media. This was especially true for those of us who build applications based on operating systems and development tools created within the last decade. It's pretty humorous when you look back on it all. Rumors of the death of your company's information system were obviously greatly exaggerated.
Then again, does the press really ever know what's going on in our industry? They missed the fact that it was a century bug and not really a millennium bug. The problem was rooted in the use of two-character dates instead of four-character dates. If the human race had had the same technology 100 years earlier, we would have faced all the same issues on New Year's Eve of 1899. However, "millennium bug" sounded so much more sensational and, consequently, sold more newspapers and magazines.
Remember a few years back when the press predicted that everything would be rewritten in Java, including the United States Constitution and the Magna Carta? Now the Java buzz has subsided and we see Java for what it is--a young and promising language with its share of strengths and weaknesses. It didn't take the industry by storm. It's a language that's usable in some situations but unsuitable in others.
Now everybody's talking about XML as the cure-all technology. I know that as XML matures, we'll find more and more uses for it. It will solve lots of problems that are very hard and very real. But XML will never replace technologies such as COM, Corba, and Java, as many people have suggested. It's important that we keep all these new technologies in perspective. It's not healthy to get overly excited about a technology that might solve all your problems a few years down the road when you have to ship an application in the next few months.
Why Should You Use COM+?
I'll assume that you are at least considering using COM+ to build distributed applications. Many companies are using COM+ and Microsoft Windows® 2000 because they provide a robust development platform. This platform is made up of several core technologies that provide the basic building blocks for constructing multitier business applications. And, after all, the more the underlying platform brings to the table, the less code you have to write and debug.
I probably don't need to convince you that multitier applications offer many advantages over the two-tier applications that were in vogue in the late 1980s and early 1990s. Your company has probably already decided to abandon the two-tier approach in favor of a multitier strategy. However, I'd like to take a little time at the beginning of this article to review the most significant problems with two-tier applications and explain how multitier applications provide solutions to many of these problems. I'll also discuss why multitier development introduces some new problems and additional complexities.
One of Microsoft's goals in developing COM+ has been to offer companies the benefits of multitier applications while hiding as much of the inherent complexity as possible. Over the last decade, Microsoft has made many advances in creating this infrastructure for distributed applications.
The first version of COM shipped in 1993. Since that time, COM has grown from a young and complicated technology into the core of Microsoft's multitier strategy. This article examines COM's most important milestones. Along the way, I'll also do my best to define all the acronyms that those marketing folks have generated over the years. You've probably heard of OLE, DCOM, ActiveX®, and MTS. COM+ and DNA are the two most recent additions to the list. But have you ever tried to explain the difference between these terms to someone at a cocktail party? It's not easy, is it? They all mean different things to different people.
The article concludes with a high-level overview of the distributed services that have been integrated into the COM+ platform. Any nontrivial multitier application requires such things as transaction support, integrated security, a Web server, messaging, and delivery of event notifications. This article will identify where each of these COM+ services fits in. This should give you an appreciation for COM+ as a whole and show you the light at the end of the tunnel.
From Two-Tier to Multitier Systems
One of the best reasons to use COM+ is to move a company's information systems from a two-tier architecture to a multitier architecture. This transition requires the design and creation of a middle-tier layer of business objects. Business objects usually sit between client applications and database servers. COM+ serves as the platform for these types of systems.
Two-tier systems have been widely deployed in the industry, so the problems associated with them are well known. Let's review the key shortcomings of a traditional two-tier architecture, such as the one shown in Figure 1.
The station runs on VBScripts running in MTS talking to an Access database. Complex vector analysis computations are done in Excel. Commications with station are via IM and IIS. The station arm talks to the rest of the station via DCOM.
All in all, the computer system is extremely robust, and expected to last for 25 years with only the occassional microsoft patch.
The regional bells only have dominance for one reason. DSL like any utility requiring infrastructure is a regional game. Covad and the late NorthPoint attempted to national with their service. That's like starting a nation-wide plumming service. While these large DSL providers are struggling, the smaller, local DSL providers are having a boom time. Nobody likes the phone company. Nobody wants to work for the phone company either. This in the end will give the smaller regional DSL providers a competative advantage over the bells. They will be able to provide infinitely better service than the phone company will ever be able to. However, trying to scale such a service to a national (or international) level will dismantel that strategic advantage.
req: HELLO
res: RUSPAM
req: YES
res: GOFUCKYOURSELF
req: OKSHOULDIKILLTHESENDER
res: YES
req: OKCRASHINGSENDERBOX
[...connection closed...]
I know of an ISP, DigitalAgent in Atlanta that uses webcams to monitor the server rooms.
Hemos is off his rocker. IBM could care less about MySQL, and Postgres. IBM is pitched in a battle with Sun in the enterprize server market. The database machine is often the big piece of hardware that enterprize sites buy, and it dictates the type of storage array and software they'll use. Sun + Oracle has a nice ring to it when you are talking about laying down $40,000+ for a database. That's were IBM and Informix come it. With a top of the line Database (I'm not sure what is wrong with DB/2), IBM can compete with Oracle, which really means that they can compete with Sun.
It is a tough call, but in the generic platform enviroment of Linux, I think jiffies have to go the way of the 5" floppy. The overhead for refined timers is quite expensive, however it probably could be eliminated with some hardware specialization.
Of course HZ is the number of timer interupts per second. 1024 is the propper setting for an Alpha chip. If you are running an alpha, this may be why your performance has increased. However, it appears your are running x86, in which case you should probably not set the HZ to 1000. The increased interupts will greatly reduce the performance of User mode applications, given that the kernel will run more frequently. Basically, your CPU had better scream in order to run with a 1 millisecond tic (1000HR). If your are running some screaming P3 or P4, the 1024 setting might not be a bad idea, but I may be fudding that fact.
Once again, someone proves that NT's only security is that it is likely to crash while your cracking it.
reverse crc compressions:
For every block of real data:
data[blocksize]
compressed data:
data[blocksize - 2] + crc
The crc is only 1 byte and can be defined as the crc of this block and the previous crc. The decompressor then chops through the data, when a crc comes up incorrect, it goes back and chooses a different possible value for a proceeding crc until the entire series of datablocks validates.
Aside for not clarifying the use of external dictionaries as being illegal (Mike let Patrick use the filesystem filenames to store data), Mike also didn't clarify processing time. If processing time is not a factor, you can create reverse CRC/Checksum compression that is acurate almost everytime. Reverse-crc compression is accurate inversely porportionate to the rate of compression. So, you simply need to choose an large data block (1 gig or so) to compress with a very low rate of compression, say 1000/999 or something like that. Then you let the reverse crc decompressor work on it for a few days, and eventually you'll come up with the right data 999/1000 times.
One solution however impractical an imperfect is to reverse-checksums. Essentially, you take the data block and perform a series of running checksums (like CRCs). You store only the checksums in the "compressed" file plus tidbits of "hint" real data. What you have is a lossy form of compression. However, with enough processing power (a few dozen E10,000s) you can reverse calcuate the checksums which will give you accurate results with 99.999+% of data blocks (some data blocks will return false solutions). It is simply a matter of home much processing time you are willing to throw at the problem.
Clearly, this is the crux of the arguement, and intellegent people can waiver here. In a sense the fragments were compressed in that the 5's were chopped off. I would actually argue that this is a form of compression, however impractical in this case. For example, if you create a dictionary of "phrases" and install the dictionary within the decompressing client, and send the "compressed" files you are really doing the same thing that Patrick did. The difference, is that Patrick exploited the filesystem to store his dictionary data, as opposed to actually putting the dictionary inside the decompressor. In fact what he did IS compression, and the files were compressed in size. Patrick could have done even more devious techniques by moving all of the data into the filenames themselves. Because Mike did not spesify that external linkage to datasources was illegal, what Patrick did in my view was within the confines of the contest.
Thats the question that I have. This makes no sense. DB/2 has the same distribution that Informix has, are they going to support both? I suppose that DB/2 is more of a mainframe application than Informix is, but I could be fudding that.
.
Patrick I meant can I send you a compressor and several compressed files whose total file size is less than the original uncompressed file and from which I can regenerate the original uncompressed fileMike Sure.
Pay up Mike. Pay up. You were too careless to plan out the rules and think about your intent before you threw 5k into the sink. Cough up the cash or loose all honor.
At first, when I was reading the page, I felt that Patrick clearly cheated, given that he exploited the filesystem to store data. However, after reading your comment, I must agree. Mike should have clarified the rules. Clearly, Patrick deserves the cash.
First of all, the decompressor was aloud to be written in shell scripts. There are all sorts of hacks one could do if you are able to link to other code for your decompressor. It should have have to have been written in C, and should have have to have relied on stdin.
Yes, mdev 7.0 is probably one of the most compliant C++ compilers out there. It is one of the few linkers than handles template-objectfile redundancy propperly without tedious pragma's and bizzare typedefs in cpp files. Also, the msdev implementation of STL and IOStreams is to the letter of the standard with full template iostreams (unlike g++ non-template IOStreams). However, msdev's implementation includes nothing that is not in the standard (like hashtables), except auto_ptr. All in all, Microsoft has embraced C++ big time (MFC and especially ATL). Frankly their devotion to that sad ancient religion, hasn't helped them conjour up the stolen data plans nor given them clairvoyance enough to learn the location of the rebels hidden fort...kha..cc.cka..aaak.
I would hope that any changes to the standard will focus on the C++ Standard Lib and not so much on language semmantics/features. The C++ library is in need of some serious features. While I recognize why they had to stop and finish, the work is losing ground to more complete libraries in other languages. The STL needs to be completed, and dare I say, some of the implementation should even be standardized. Certainly, the interfaces should be standardized. My God, lets make hash tables official, and pick an implementation. Also, the iostream libs need to be expanded to include asynchronous I/O, more usable streambuffers etc. Also, the standard needs to officially ditch strstream and replace it with string_stream. As for threading, well Posix has pretty good threads, although events could be wrapped up a bit neater (like dare I say in win32). As for handles and such, it would be in the C spirit, as the standard C lib has things like FILE and such.