This is long, but this is a problem I've been thinking about for a LONG time, so please bear with me and hear me out.
I personally think that all forms of RPC are way over-hyped, and not actually terribly useful in the majority of situations in which you'd be tempted to use them. I know this is an unusual point of view, and needs justification.
As a broad outline, you can plot different forms of IPC on a graph with one axis being speed, and the other coupling or, it's inverse, portability. Speed and coupling, like space and time complexities in algorithms, can be related, but, IMHO, are largely orthogontal.
For example, one nieve form of IPC that I've seen commonly is for raw memory to be dumped onto a socket or a pipe. This is great for speed, but very bad for coupling (i.e. very non-portable). It might not even work for two different compilers on the same platform, and if you're trying to communicate between two different languages, each program needs to know intimate details about how the other lays things out in memory. Also, nievely implemented, with little thought given to minimizing round-trip requests, it often isn't as fast as you'd think. (More on that later).
At the opposite corner in the graph are protocols like SMTP, or even worse, XML over HTTP. SMTP communicates using text messages that have to be parsed. SMTP parsing is pretty simple, although, looking at sendmail, it can get pretty hairy. XML parsing is even more complex. These parsing steps slow things way down. On the other hand, the well defined nature and robust structure of these protocols makes them extremely portable (i.e. low coupling).
Now, the question to ask is where does RPC fit into all of this?
Well, if you think about it, all forms of RPC, including CORBA, require a fairly explicit detailing of the messages to be sent back and forth. You have to specify your function signature pretty exactly, and the other side has to agree with you. Also, the way RPC encourages you to design protocols tends to create protocols in which the messages have a pretty specific meaning. In contrast, the messages in the SMTP or XML protocol have a pretty general meaning, and it's up to the program to interpret what they mean for it. This bumps RPC protocols up on the coupling scale a fair amount, despite the claims of the theorists and marketers.
OTOH, the messages are platform and language independent. It's relatively easy to find a binding for any given language. Usually the code to decode the message from a bytestream and call your function is generated for you. And, the bytestream will be the same if you get your message from a perl program or a C++ program. This bumps it down on the coupling scale from the memory dumping protocols.
As far as speed is concerned, there are two main problems.
One is minor in that almost any protocol that is supposed to be language and platform independent is going to have it. That problem is marshalling. You have to get your data from the format your language keeps it in into your wire format and back again. While this problem is not as computationally intensive as parsing, it still exists.
The other is major. The one thing you always want to avoid in any networking protocol is round trip requests. Round trip requests will always be inherently slow, if for no other reason than the speed of light. You never want to wait for your message to be processed, and a reply sent before you send another message. The X protocol works largely because it avoids round-trip requests like the plague. There is a noticeable lag when an X program starts up because the majority of the unavoidable round trip requests (for things like font information and a bunch of window ids and stuff) are made then. Even when the programs are on the same computer, round trip requests force context switches which eat CPU time. In short, they are BAD.
Any RPC oriented protocol encourages you to think of the messages you are sending as function calls. In every widely used programming language, functions calls are synchronous. Your program 'waits' for the result of a function call before continuing. This encourages thinking about your RPC interface in entirely the wrong way. It doesn't make you focus on the messages you're sending, and the inherently asynchronous nature of such things. It makes you focus on the interface as you would a normal class interface, or a subsystem interface. This leads to lots of round-trip requests, which is a major problem.
CORBA generally advocates soloving this problem by making heavy use of threading. But multiple threads have a lot of problems. They just move the descisions about handling asynchronous behavior to the most difficult part of your program to deal with it in, your internal data structures. Not only that, but multiple threads are a big robustness problem. It's difficult to deal with the failure of a single thread of a multi-threaded program in an intelligent way, especially if the job of that thread is intimately intertwined with what another thread is doing.
Also, threads end up taking up a lot of resources. Both obvious ones like context switches and space for processor contexts, and in less obvious ones, like stack space. One program I saw had a thread for every communcations stream, and it needed to deal with over 300 streams at a time. It also needed a stack of 1M for each thread because some function calls ended up being deeply nested. That's at least 300M just for stack space. The program may have had no difficulty dealing with 300 communications streams at once had it not used threads. As it was, it constantly ran out of memory.
In short, CORBA, and other RPC solutions look like a quick and easy answer to a difficult problem, but, measured on the coupling and speed scales, they are medium to highly coupled, and medium to low speed. Not as bad on speed as, perhaps, XML, but not all that great either.
I would like to see (and am in the process of creating) a very message oriented tool for building communications protocols. It would concentrate heavily on what data the messages contained, not what the expected behavior of a program receiving the message should be. It would be supported by a communcations subsystem that emphasized the inherently asynchronous nature of IPC, and made it easier to build systems that used that to provide efficient communcations. It would provide auto-generated marshalling and unmarshalling of data, and even a provision for fetching metadata describing unkown messages, much like XML. It would also allow you to easily override the generated functions with your own functions that are tuned to the data you're sending. It would also make it easy to build and layer new protocols on top of existing ones, or transparently extend protocols in such a way that old programs would still work.
As a last note, I would like to say that we've known for years how to handle the inherently asynchronous nature of user interaction. All of our UI libraries are heavily event oriented. Processing is either split up into small discreet chunks that can be handled quickly inside an event handler, or split off into a seperate thread that communicates to the main program mainly through events. We need the same kind of architecture for programs that do IPC.
If anybody is interested in the beginnings of such a system, I have an open source project that I think is still in the 'cathedral' stage. I would like help and input on its development though, and I need help making it easy to port and compile in random environments. If you would like to help, please e-mail me. I call the system the StreamModule system, and it's architecturally related to the idea of UNIX pipes.
I find the constant relabelling of various mechanisms by which bad ideas are weeded out as 'censorship' to be kind of amusing, and sort of dangerous.
I wonder if the various and diverse groups of people who do this sort of relabelling realize that they're weakening an important and appropriately alarming word in the hopes of lending its strength to their opinion?
I would like to make one point that seems to be being ignored by most. The point is that taking any systematic action that would reduce the diversity of the human gene pool should be approached with the greatest trepidation.
Sickle cell anemia exists because the gene that causes it also protects from malaria, and is beneficial to the carrier when only one copy is present. The ruthlessness of natural selection has largely weeded this gene out of the human population in areas where the malaria parasite isn't found, but in areas where it is, this gene is reasonably common.
My question is, what are we wiping out when we systematically decide that people with a certain defect should be killed at birth? Are we wiping out the only people who'll be resistent to the next plague? Are we wiping out the ability to think and put ideas together in a certain way from the general (non-disabled) population? What is the hidden cost?
I do find something wrong with his premises. A brain-dead person will never become conscious again. An infant, given time and care, will be, even if it may not be when it's born.
I won't say anything more than this though as I haven't thought through the issue really carefully. I just wanted to point out the point that Tau Zero made is not as airtight as (s)he thinks.
One idea that a friend had was this: Rescind all of the government supported intellectual property for their operating system products. They haven't played nice with the limited monopoly they've been granted via IP (intellectual property) law, so deny them all of its protections.
I think this sets a good precendent for a lot of companies. It forcibly drives home the fact the IP is not a natural right, but a government sponsored right, and it denies Microsoft a chief advantage.
So, in closing, I say, deny them all of their current IP rights, and on any new IP created for the next 1-2 years. That's a penalty that will hit them where it hurts, will provide a huge benefit to everyone else, and sets a good precedent in IP law.
The difference here is that most Open Source projects are open about their bugs, and make an honest effort to fix them.
As for the malloc check problem... I never check my mallocs. I tend to try to arrange it so the program will segfault if a malloc ever returns 0. The problem is that out-of-memory errors are really hard to deal with properly, and I doubt that it's worth the effort and code bloat to do so. One nice thing about C++ (and Java) is that new throws an exception, which makes out-of-memory errors much easier to deal with.:-)
There have been a lot of statements along the lines of 'C++ is slower than C'. After being puzzled by where this perception came from, I realize it came from Visual C++ development under Windoze. This end up being slow there becuase of both the pressure people in that environment are under, and the slow and badly designed nature of the function call libraries masquerading as an OS that they have to work with.
In my experience C++ is as fast, or faster than C.
Sure, virtual functions impose a tiny bit of overhead. So does RTTI. Exceptions also introduce some overhead, though implementations are getting better.
The speedup doesn't come from using these features directly. It comes from the flexibility afforded the programmer. Want to switch from using a list to using a tree because you discovered that your list is unexpectedly holding thousands of elements instead of the expected few dozen? No problem. Want to have a more elegant and faster way than a switch statement of picking the right thing to do for a particular type of data? No problem.
And that's just a sampling. Done correctly, C++ both leverages optimization efforts and makes them easier.
I find this dislike of C++ in the open source community to be very upsetting and distressing. It puzzles me how a bunch of people who claim to have open minds can reject a language out of hand that is so obviously useful and worthwhile. One can only suspect that the declaration of open mindedness is a facade and that they're horribly afraid of learning anything new.
PS. To me, GTKs main disadvantage is that it isn't written in an OO language. I though that people, after seeing what a cock-up Xt is, would've known better.
Why should I have to change my behavior or dress to conform to someone else's ideal? Why should I be beat up for being different? Why should I be forced to adapt to anti-social behavior?
*sigh*
An open letter to Confinity
on
Beaming Money
·
· Score: 1
Are you going to publish the protocol used to communicate with your servers, and between handheld devices?
I own a Palm Pilot, but I use Linux, and I'm worried about my ability to use your service.
I'm also concerned about the security of any non-public protocol. Long experience in the cryptography community has proven that any algorithm that isn't public and survived teams of people trying to crack it isn't secure. I don't care if you use a proven algorithm like RSA. How do you use it? Where are the private keys stored? What data is on the wire? Is any data that may potentially damage security transmitted? I don't care what your answers are. I want other people's answers.
I'm looked at as a technology advisor by a lot of my friends. I will advise them all to not use your service due to the problems I outlined above unless you publish your protocol for peer review.
The main effect of stupid laws is to reduce overall respect for the law. You're looking at the problem from the wrong direction, and blaming people for having a lack of respect for the law instead of blaming the law for being stupid.
There are no legitimate law enforcement or national security concerns. Janet Reno did not provide one shred of evidence. She just pointed out some vague scenario that has no basis in reality. It's not even clear that the position she was taking would've prevented the scenario she described.
As was pointed out by many other people, in one sense, comparisons between XML and CORBA are somewhat silly since they address two very different problem domains.
In another sense, comparing them reveals a fairly deep insight into what's really going on with these two technologies. Both CORBA and XML, are, in a broad sense, attempts to address the problem of messaging (getting two different programs that don't have anything to do with one another to communicate (pass data back and forth when they don't share any address space) properly).
In my opinion, there are two axis on which one can judge a messaging technology. One is efficiency, and the other is coupling.
For example, one common method that people used to use to write programs that had to talk to one another was to directly dump program data memory (write structs) into whatever data stream you were using to communicate with. This is off the scale on the coupling axis, but has the advantage of being generally very efficient. Because the coupling between programs that communicate this way is so high (it's so high that two programs sharing a common code base, but compiled for different architectures may not be able to communicate) this approach is usually dismissed.
XML is very, very low on the coupling scale. There's even a standard describing high semantic content meta data that's used to describe the messages being exchanged. On the other hand, it's also very low on the efficiency scale. You have to translate all of your data to a structured framework of textual tags with largely textual content. This makes XML suitable only for applications in which low coupling is at a premium. Long term archival storage, or transmitting data across the net between diverse, unrelated parties are two examples of such applications.
CORBA has higher coupling. The two programs have to agree on the function call interfaces that will be used to communicate. It's also more efficient. The data is translated to a binary form that's negotiated between the parties so that there's a minimum CPU time cost in the translation. So CORBA occupies sort of a middle of the road strategy. It's perfect for things like GNOME, where you can count on all the applications using the same toolkit, but not necessarily running on the same architecture.
I think CORBA's coupling is too high though. Also, it's reliance on a function call style model encourages the development of messaging protocols that are highly inefficient due to excessive round trip messages. I'm currently working on a somewhat different architecture that concentrates heavily on having a machine independent way of describing the content of an efficiently encoded message which I will call CDL (Common Data Language). The semantic coupling implied by CORBA's function call model would be absent because the architecture wouldn't describe the messages in terms of function calls, but merely in terms of the data to be exchanged. This pushes it much closer to XML on the coupling axis.
Anway, this is a topic with a lot of subtleties, and one that I'm very interested in. If any of you want to talk about messaging and messaging architectures, I'd welcome the exchange of ideas.
If anybody wants to help me build this thing, I'd also very much appreciate it. Be warned that it's written in C++, and I'm NOT going to do it in C. C's expressive power has been long eclipsed by C++, and it's high time that people stopped complaining about how complicated it is and actually learned something new. The Open Source community's penchant for simplicity is laudable, but C++'s power is well worth the complexity.
I think a high line count is a strong negative factor when evaluating software. Every line is a potential bug. The more lines you have, the more bugs you have.
It amuses me that Microsoft constantly touts how many lines of code their software has, as if that were somehow a feature, or a positive thing. To me, it's just a measure of how unlreliable the software is likely to be.
I found early Wired to tie the world together in an amazingly insightful way. They took the cultural, economic, and technological forces that shape our lives and showed how they wove together in an intricate tapestry of interaction.
That phrase reminds of of John Conway's game of life. A simple cellular automata showing a complex mosaic of interaction with every tick of the clock. While this is an idea that may not have graced the pages of Wired, this sort of wild connection between mathematics and sociology is just the sort of thing you'd expect from them.
I grew disgusted when the vaunted idea that the 'net' would be some kind of political force in the 1992 election was proven false by the outcome. In my mind, Wired had become populated with starry eyed idealists with a tenuous grasp on reality. I dropped my subscription.
Most of the people I know who disliked Wired during the time I liked it were the kind of people who didn't have the imagination to see beyond the edges of their CRT. Most of the technical people I know who had the wit to understand that what they did had cultural significance thought the magazine was pretty interesting.
I lack the hard (no pun intended) data to back this up, but I think that hard-drive raw transfer rates have been rising and access times have been falling. I will agree that they haven't gotten better anywhere near as quickly as other parts of a computer system though.
That being said, the only thing I can see as being an eventual competitor to hard-drives is the drawing board idea of holographic storage. Whether or not any products based on it ever make it to market is anyone's guess.
Thank you ever so kindly for your insight. Now, if you would be so nice as to actually write something capable of reading something described by that tangled mess, please do so. I think you will find that, as has been demonstrated by other attempts, it is extremely difficult.
I don't think Microsoft opening up its document format standards is such an excellent idea, mostly because I don't think it will matter whether or not they're open.
Standards bodies around the world have often demonstrated how to make biased or impossible to implement standards. In my darker moments I think of my favorite (only a slight touch of sarcasm is meant there) language, C++.:-)
I think the current trend towards XML and XSL is a much better way to beat back this particular head of the Microsoft monopoly hydra.
If you have a lot of computers that you need to do this with within the same organization, and are willing to accept a power off via a UPS in lieu of pressing the reset button, our company (Global Maintech) has a solution that will work over a LAN or WAN.
It's actually designed to be a full management product that allows remote access to your consoles, along with the ability to run scripts that scan for stuff and automatically post alerts or do things in response to messages.
All you'll get with this approach is a bland, overly intellectual letter that has about as much strength and passion as a piece of overcooked spaghetti.
Committees can't write stuff. Good writing comes from the heart and mind of an individual, not from some committee that has distilled everyone's opinions and mulched them into some kind of grotesque, overly polite frankensteinian monster.
Of course, the square wave harmonics drop off (technically without actually ever reaching 0) as the frequency increases. You'll get some high frequency leakage, but I don't think it'll be that much of a problem.
If I were an EE person, I'd even post the equation for the amount of signal power vs. frequency in a square wave.:-)
As a few people have stated, C++ gives you the power to fix the buffer overflow problem once and for all.
As a few other people stated, recoding the standard libraries is considered unacceptable when you're on a schedule.
My response to these people is "What do you think Open Source is for anyway?". Find a library that fixes the problem, and use it. No need for you to do any coding.
I, personally have a library I've used for several projects that eliminates the buffer overflow problem. It also permits a lot of data stream processing, chopping, and hacking to pieces without needing to make a single copy. One of these days, I'll even publish it under GPL.
Your comment doesn't completely address his concerns. Being able to sneak an arbitray return address allows you to execute almost arbritrary code whether the stack is considered executable or not.
With a commerical product like IE, the attacker will have complete knowledge of all the code loaded into memory. Just jump to some bit of normally executable code in memory that does what you want. On an Intel chip, you don't even have to jump to an instruction that originally existed. Jump into the middle of an instruction and you get code that the designers never intended to be put there.
I fervently hope that this bug is used to repeatedly down the stock market and a few military computers. That would put the spotlight like nothing else on Microsoft's failings.
The previous posts have done a good job of reporting what sar is for. It's a system activity logger that reports a very wide range of different system activity measurements over a period of time. It's very useful when you're trying to pin down why your system is being slow, or what resource your running out of and need to buy more of.
From what I've seen in my week or two of playing with Linux is that Linux has the best realtime system performance monitoring I've ever seen in a UNIX, but very little long-term reporting like what sar does. For this reason, sar could be very useful.
Of course, writing a little shell script in Linux that cats certain/proc files into a log periodically may be able to duplicate much of the functionality of sar.
I don't think Frontier is a baby bell. I visited their heart in Rochester because our company installed a product there (that they later returned, battered and broken).
Frontier is known in the MN area as having atrociously bad customer service. Until they closed the office here in the Twin Cities, when you walked in to talk to someone, you were greeted with a row of phones in front of a big pane of bulletproof glass that didn't have any people behind it.
Stability as a marketing message is good for now. One's marketing message must always be simple, and to the point. It's also allowed to change over time. Stability is the buzzword of today because not a lot of people understand GPL or why it's a good thing. Maybe, if Microsloth is up to the task of making their OS stable, GPL can be the message of tomorrow. Or maybe it will be performance.
The one problem with this is that it can seem disingenuous, and cause people to lose focus on what is really important. Focusing on uptime cause the 'masses' to ignore the GPL message. Worse yet, people who are part of the organization can start believing the uptime message instead of the GPL message.
I've successfully avoided saying anything here, except for laying out what kinds of problems there are to deal with.:-)
Slashdot Mirror
This is long, but this is a problem I've been thinking about for a LONG time, so please bear with me and hear me out.
I personally think that all forms of RPC are way over-hyped, and not actually terribly useful in the majority of situations in which you'd be tempted to use them. I know this is an unusual point of view, and needs justification.
As a broad outline, you can plot different forms of IPC on a graph with one axis being speed, and the other coupling or, it's inverse, portability. Speed and coupling, like space and time complexities in algorithms, can be related, but, IMHO, are largely orthogontal.
For example, one nieve form of IPC that I've seen commonly is for raw memory to be dumped onto a socket or a pipe. This is great for speed, but very bad for coupling (i.e. very non-portable). It might not even work for two different compilers on the same platform, and if you're trying to communicate between two different languages, each program needs to know intimate details about how the other lays things out in memory. Also, nievely implemented, with little thought given to minimizing round-trip requests, it often isn't as fast as you'd think. (More on that later).
At the opposite corner in the graph are protocols like SMTP, or even worse, XML over HTTP. SMTP communicates using text messages that have to be parsed. SMTP parsing is pretty simple, although, looking at sendmail, it can get pretty hairy. XML parsing is even more complex. These parsing steps slow things way down. On the other hand, the well defined nature and robust structure of these protocols makes them extremely portable (i.e. low coupling).
Now, the question to ask is where does RPC fit into all of this?
Well, if you think about it, all forms of RPC, including CORBA, require a fairly explicit detailing of the messages to be sent back and forth. You have to specify your function signature pretty exactly, and the other side has to agree with you. Also, the way RPC encourages you to design protocols tends to create protocols in which the messages have a pretty specific meaning. In contrast, the messages in the SMTP or XML protocol have a pretty general meaning, and it's up to the program to interpret what they mean for it. This bumps RPC protocols up on the coupling scale a fair amount, despite the claims of the theorists and marketers.
OTOH, the messages are platform and language independent. It's relatively easy to find a binding for any given language. Usually the code to decode the message from a bytestream and call your function is generated for you. And, the bytestream will be the same if you get your message from a perl program or a C++ program. This bumps it down on the coupling scale from the memory dumping protocols.
As far as speed is concerned, there are two main problems.
One is minor in that almost any protocol that is supposed to be language and platform independent is going to have it. That problem is marshalling. You have to get your data from the format your language keeps it in into your wire format and back again. While this problem is not as computationally intensive as parsing, it still exists.
The other is major. The one thing you always want to avoid in any networking protocol is round trip requests. Round trip requests will always be inherently slow, if for no other reason than the speed of light. You never want to wait for your message to be processed, and a reply sent before you send another message. The X protocol works largely because it avoids round-trip requests like the plague. There is a noticeable lag when an X program starts up because the majority of the unavoidable round trip requests (for things like font information and a bunch of window ids and stuff) are made then. Even when the programs are on the same computer, round trip requests force context switches which eat CPU time. In short, they are BAD.
Any RPC oriented protocol encourages you to think of the messages you are sending as function calls. In every widely used programming language, functions calls are synchronous. Your program 'waits' for the result of a function call before continuing. This encourages thinking about your RPC interface in entirely the wrong way. It doesn't make you focus on the messages you're sending, and the inherently asynchronous nature of such things. It makes you focus on the interface as you would a normal class interface, or a subsystem interface. This leads to lots of round-trip requests, which is a major problem.
CORBA generally advocates soloving this problem by making heavy use of threading. But multiple threads have a lot of problems. They just move the descisions about handling asynchronous behavior to the most difficult part of your program to deal with it in, your internal data structures. Not only that, but multiple threads are a big robustness problem. It's difficult to deal with the failure of a single thread of a multi-threaded program in an intelligent way, especially if the job of that thread is intimately intertwined with what another thread is doing.
Also, threads end up taking up a lot of resources. Both obvious ones like context switches and space for processor contexts, and in less obvious ones, like stack space. One program I saw had a thread for every communcations stream, and it needed to deal with over 300 streams at a time. It also needed a stack of 1M for each thread because some function calls ended up being deeply nested. That's at least 300M just for stack space. The program may have had no difficulty dealing with 300 communications streams at once had it not used threads. As it was, it constantly ran out of memory.
In short, CORBA, and other RPC solutions look like a quick and easy answer to a difficult problem, but, measured on the coupling and speed scales, they are medium to highly coupled, and medium to low speed. Not as bad on speed as, perhaps, XML, but not all that great either.
I would like to see (and am in the process of creating) a very message oriented tool for building communications protocols. It would concentrate heavily on what data the messages contained, not what the expected behavior of a program receiving the message should be. It would be supported by a communcations subsystem that emphasized the inherently asynchronous nature of IPC, and made it easier to build systems that used that to provide efficient communcations. It would provide auto-generated marshalling and unmarshalling of data, and even a provision for fetching metadata describing unkown messages, much like XML. It would also allow you to easily override the generated functions with your own functions that are tuned to the data you're sending. It would also make it easy to build and layer new protocols on top of existing ones, or transparently extend protocols in such a way that old programs would still work.
As a last note, I would like to say that we've known for years how to handle the inherently asynchronous nature of user interaction. All of our UI libraries are heavily event oriented. Processing is either split up into small discreet chunks that can be handled quickly inside an event handler, or split off into a seperate thread that communicates to the main program mainly through events. We need the same kind of architecture for programs that do IPC.
If anybody is interested in the beginnings of such a system, I have an open source project that I think is still in the 'cathedral' stage. I would like help and input on its development though, and I need help making it easy to port and compile in random environments. If you would like to help, please e-mail me. I call the system the StreamModule system, and it's architecturally related to the idea of UNIX pipes.
I find the constant relabelling of various mechanisms by which bad ideas are weeded out as 'censorship' to be kind of amusing, and sort of dangerous.
I wonder if the various and diverse groups of people who do this sort of relabelling realize that they're weakening an important and appropriately alarming word in the hopes of lending its strength to their opinion?
I would like to make one point that seems to be being ignored by most. The point is that taking any systematic action that would reduce the diversity of the human gene pool should be approached with the greatest trepidation.
Sickle cell anemia exists because the gene that causes it also protects from malaria, and is beneficial to the carrier when only one copy is present. The ruthlessness of natural selection has largely weeded this gene out of the human population in areas where the malaria parasite isn't found, but in areas where it is, this gene is reasonably common.
My question is, what are we wiping out when we systematically decide that people with a certain defect should be killed at birth? Are we wiping out the only people who'll be resistent to the next plague? Are we wiping out the ability to think and put ideas together in a certain way from the general (non-disabled) population? What is the hidden cost?
I do find something wrong with his premises. A brain-dead person will never become conscious again. An infant, given time and care, will be, even if it may not be when it's born.
I won't say anything more than this though as I haven't thought through the issue really carefully. I just wanted to point out the point that Tau Zero made is not as airtight as (s)he thinks.
One idea that a friend had was this: Rescind all of the government supported intellectual property for their operating system products. They haven't played nice with the limited monopoly they've been granted via IP (intellectual property) law, so deny them all of its protections.
I think this sets a good precendent for a lot of companies. It forcibly drives home the fact the IP is not a natural right, but a government sponsored right, and it denies Microsoft a chief advantage.
So, in closing, I say, deny them all of their current IP rights, and on any new IP created for the next 1-2 years. That's a penalty that will hit them where it hurts, will provide a huge benefit to everyone else, and sets a good precedent in IP law.
The difference here is that most Open Source projects are open about their bugs, and make an honest effort to fix them.
As for the malloc check problem... I never check my mallocs. I tend to try to arrange it so the program will segfault if a malloc ever returns 0. The problem is that out-of-memory errors are really hard to deal with properly, and I doubt that it's worth the effort and code bloat to do so. One nice thing about C++ (and Java) is that new throws an exception, which makes out-of-memory errors much easier to deal with. :-)
There have been a lot of statements along the lines of 'C++ is slower than C'. After being puzzled by where this perception came from, I realize it came from Visual C++ development under Windoze. This end up being slow there becuase of both the pressure people in that environment are under, and the slow and badly designed nature of the function call libraries masquerading as an OS that they have to work with.
In my experience C++ is as fast, or faster than C.
Sure, virtual functions impose a tiny bit of overhead. So does RTTI. Exceptions also introduce some overhead, though implementations are getting better.
The speedup doesn't come from using these features directly. It comes from the flexibility afforded the programmer. Want to switch from using a list to using a tree because you discovered that your list is unexpectedly holding thousands of elements instead of the expected few dozen? No problem. Want to have a more elegant and faster way than a switch statement of picking the right thing to do for a particular type of data? No problem.
And that's just a sampling. Done correctly, C++ both leverages optimization efforts and makes them easier.
I find this dislike of C++ in the open source community to be very upsetting and distressing. It puzzles me how a bunch of people who claim to have open minds can reject a language out of hand that is so obviously useful and worthwhile. One can only suspect that the declaration of open mindedness is a facade and that they're horribly afraid of learning anything new.
PS. To me, GTKs main disadvantage is that it isn't written in an OO language. I though that people, after seeing what a cock-up Xt is, would've known better.
Why should I have to change my behavior or dress to conform to someone else's ideal? Why should I be beat up for being different? Why should I be forced to adapt to anti-social behavior?
*sigh*
Are you going to publish the protocol used to communicate with your servers, and between handheld devices?
I own a Palm Pilot, but I use Linux, and I'm worried about my ability to use your service.
I'm also concerned about the security of any non-public protocol. Long experience in the cryptography community has proven that any algorithm that isn't public and survived teams of people trying to crack it isn't secure. I don't care if you use a proven algorithm like RSA. How do you use it? Where are the private keys stored? What data is on the wire? Is any data that may potentially damage security transmitted? I don't care what your answers are. I want other people's answers.
I'm looked at as a technology advisor by a lot of my friends. I will advise them all to not use your service due to the problems I outlined above unless you publish your protocol for peer review.
The main effect of stupid laws is to reduce overall respect for the law. You're looking at the problem from the wrong direction, and blaming people for having a lack of respect for the law instead of blaming the law for being stupid.
There are no legitimate law enforcement or national security concerns. Janet Reno did not provide one shred of evidence. She just pointed out some vague scenario that has no basis in reality. It's not even clear that the position she was taking would've prevented the scenario she described.
As was pointed out by many other people, in one sense, comparisons between XML and CORBA are somewhat silly since they address two very different problem domains.
In another sense, comparing them reveals a fairly deep insight into what's really going on with these two technologies. Both CORBA and XML, are, in a broad sense, attempts to address the problem of messaging (getting two different programs that don't have anything to do with one another to communicate (pass data back and forth when they don't share any address space) properly).
In my opinion, there are two axis on which one can judge a messaging technology. One is efficiency, and the other is coupling.
For example, one common method that people used to use to write programs that had to talk to one another was to directly dump program data memory (write structs) into whatever data stream you were using to communicate with. This is off the scale on the coupling axis, but has the advantage of being generally very efficient. Because the coupling between programs that communicate this way is so high (it's so high that two programs sharing a common code base, but compiled for different architectures may not be able to communicate) this approach is usually dismissed.
XML is very, very low on the coupling scale. There's even a standard describing high semantic content meta data that's used to describe the messages being exchanged. On the other hand, it's also very low on the efficiency scale. You have to translate all of your data to a structured framework of textual tags with largely textual content. This makes XML suitable only for applications in which low coupling is at a premium. Long term archival storage, or transmitting data across the net between diverse, unrelated parties are two examples of such applications.
CORBA has higher coupling. The two programs have to agree on the function call interfaces that will be used to communicate. It's also more efficient. The data is translated to a binary form that's negotiated between the parties so that there's a minimum CPU time cost in the translation. So CORBA occupies sort of a middle of the road strategy. It's perfect for things like GNOME, where you can count on all the applications using the same toolkit, but not necessarily running on the same architecture.
I think CORBA's coupling is too high though. Also, it's reliance on a function call style model encourages the development of messaging protocols that are highly inefficient due to excessive round trip messages. I'm currently working on a somewhat different architecture that concentrates heavily on having a machine independent way of describing the content of an efficiently encoded message which I will call CDL (Common Data Language). The semantic coupling implied by CORBA's function call model would be absent because the architecture wouldn't describe the messages in terms of function calls, but merely in terms of the data to be exchanged. This pushes it much closer to XML on the coupling axis.
Anway, this is a topic with a lot of subtleties, and one that I'm very interested in. If any of you want to talk about messaging and messaging architectures, I'd welcome the exchange of ideas.
If anybody wants to help me build this thing, I'd also very much appreciate it. Be warned that it's written in C++, and I'm NOT going to do it in C. C's expressive power has been long eclipsed by C++, and it's high time that people stopped complaining about how complicated it is and actually learned something new. The Open Source community's penchant for simplicity is laudable, but C++'s power is well worth the complexity.
I think a high line count is a strong negative factor when evaluating software. Every line is a potential bug. The more lines you have, the more bugs you have.
It amuses me that Microsoft constantly touts how many lines of code their software has, as if that were somehow a feature, or a positive thing. To me, it's just a measure of how unlreliable the software is likely to be.
I would beg to disagree.
I found early Wired to tie the world together in an amazingly insightful way. They took the cultural, economic, and technological forces that shape our lives and showed how they wove together in an intricate tapestry of interaction.
That phrase reminds of of John Conway's game of life. A simple cellular automata showing a complex mosaic of interaction with every tick of the clock. While this is an idea that may not have graced the pages of Wired, this sort of wild connection between mathematics and sociology is just the sort of thing you'd expect from them.
I grew disgusted when the vaunted idea that the 'net' would be some kind of political force in the 1992 election was proven false by the outcome. In my mind, Wired had become populated with starry eyed idealists with a tenuous grasp on reality. I dropped my subscription.
Most of the people I know who disliked Wired during the time I liked it were the kind of people who didn't have the imagination to see beyond the edges of their CRT. Most of the technical people I know who had the wit to understand that what they did had cultural significance thought the magazine was pretty interesting.
I lack the hard (no pun intended) data to back this up, but I think that hard-drive raw transfer rates have been rising and access times have been falling. I will agree that they haven't gotten better anywhere near as quickly as other parts of a computer system though.
That being said, the only thing I can see as being an eventual competitor to hard-drives is the drawing board idea of holographic storage. Whether or not any products based on it ever make it to market is anyone's guess.
Thank you ever so kindly for your insight. Now, if you would be so nice as to actually write something capable of reading something described by that tangled mess, please do so. I think you will find that, as has been demonstrated by other attempts, it is extremely difficult.
I don't think Microsoft opening up its document format standards is such an excellent idea, mostly because I don't think it will matter whether or not they're open.
Standards bodies around the world have often demonstrated how to make biased or impossible to implement standards. In my darker moments I think of my favorite (only a slight touch of sarcasm is meant there) language, C++. :-)
I think the current trend towards XML and XSL is a much better way to beat back this particular head of the Microsoft monopoly hydra.
If you have a lot of computers that you need to do this with within the same organization, and are willing to accept a power off via a UPS in lieu of pressing the reset button, our company (Global Maintech) has a solution that will work over a LAN or WAN.
It's actually designed to be a full management product that allows remote access to your consoles, along with the ability to run scripts that scan for stuff and automatically post alerts or do things in response to messages.
All you'll get with this approach is a bland, overly intellectual letter that has about as much strength and passion as a piece of overcooked spaghetti.
Committees can't write stuff. Good writing comes from the heart and mind of an individual, not from some committee that has distilled everyone's opinions and mulched them into some kind of grotesque, overly polite frankensteinian monster.
Of course, the square wave harmonics drop off (technically without actually ever reaching 0) as the frequency increases. You'll get some high frequency leakage, but I don't think it'll be that much of a problem.
If I were an EE person, I'd even post the equation for the amount of signal power vs. frequency in a square wave. :-)
You confuse the people with the company. The people who work for Microsoft are not our enemies, but the company as a whole is.
As a few people have stated, C++ gives you the power to fix the buffer overflow problem once and for all.
As a few other people stated, recoding the standard libraries is considered unacceptable when you're on a schedule.
My response to these people is "What do you think Open Source is for anyway?". Find a library that fixes the problem, and use it. No need for you to do any coding.
I, personally have a library I've used for several projects that eliminates the buffer overflow problem. It also permits a lot of data stream processing, chopping, and hacking to pieces without needing to make a single copy. One of these days, I'll even publish it under GPL.
Your comment doesn't completely address his concerns. Being able to sneak an arbitray return address allows you to execute almost arbritrary code whether the stack is considered executable or not.
With a commerical product like IE, the attacker will have complete knowledge of all the code loaded into memory. Just jump to some bit of normally executable code in memory that does what you want. On an Intel chip, you don't even have to jump to an instruction that originally existed. Jump into the middle of an instruction and you get code that the designers never intended to be put there.
I fervently hope that this bug is used to repeatedly down the stock market and a few military computers. That would put the spotlight like nothing else on Microsoft's failings.
The previous posts have done a good job of reporting what sar is for. It's a system activity logger that reports a very wide range of different system activity measurements over a period of time. It's very useful when you're trying to pin down why your system is being slow, or what resource your running out of and need to buy more of.
From what I've seen in my week or two of playing with Linux is that Linux has the best realtime system performance monitoring I've ever seen in a UNIX, but very little long-term reporting like what sar does. For this reason, sar could be very useful.
Of course, writing a little shell script in Linux that cats certain /proc files into a log periodically may be able to duplicate much of the functionality of sar.
I don't think Frontier is a baby bell. I visited their heart in Rochester because our company installed a product there (that they later returned, battered and broken).
Frontier is known in the MN area as having atrociously bad customer service. Until they closed the office here in the Twin Cities, when you walked in to talk to someone, you were greeted with a row of phones in front of a big pane of bulletproof glass that didn't have any people behind it.
Stability as a marketing message is good for now. One's marketing message must always be simple, and to the point. It's also allowed to change over time. Stability is the buzzword of today because not a lot of people understand GPL or why it's a good thing. Maybe, if Microsloth is up to the task of making their OS stable, GPL can be the message of tomorrow. Or maybe it will be performance.
The one problem with this is that it can seem disingenuous, and cause people to lose focus on what is really important. Focusing on uptime cause the 'masses' to ignore the GPL message. Worse yet, people who are part of the organization can start believing the uptime message instead of the GPL message.
I've successfully avoided saying anything here, except for laying out what kinds of problems there are to deal with. :-)