Microsoft's "Get the facts" campaing has been highly publicised in a wide variety of places, and frequently cites figures from studies that seem to show Windows at an advantage over Linux, yet on careful examination of these studies there are often methodological flaws in them.
I recall reading the details of one from the downloadable report on the Microsoft web site recently that compared the throughput of Windows + IIS to Linux + Apache for serving static web pages. The figures showed Windows in a clear lead, yet on closer examination it appears that the Windows installation had been thoroughly optimised (by, e.g., turning off the collection of last access information on the file system and increasing the default filesystem block size, see pages 30 & 33 of the document linked) whereas similar optimisations had not been applied to the Linux system for the test (with default configurations suggested by the distribution installer accepted for filesystem parameters, see pages 30 - 32 of the document).
How would you answer those who are concerned that by presenting these "independent" tests where the testers have followed precise instructions from Microsoft on how to optimise their products but have not (apparently) consulted Linux experts on how to optimise Linux systems as authoritative that you are unfairly distorting the truth and painting a poor picture of Linux? Is it just that you're doing your job the only way you can, because on a level playing field Linux would win? Or is the picture of these reports as unfair to Linux in some way wrong?
It's also the figure equivalent to the figure that was quoted in the grandparent article that he was comparing it to (from the 'VIRT' column of the output of top(1)), so would be the best figure to use for that purpose.
Except that most mail servers aren't designed to give the kind of delivery guarantees that message queueing software like MQSeries does.
Aren't they? I've worked on mail server software, and the primary design goal of that server was this:
Never lose a message if you've sent the confirmation that it has been received.
The techniques we used to achieve this (a journal of all incoming messages with a record of where they were delivered, so that undelivered messages can be reconstructed in event of failure) are all well known and thoroughly audited and tested, and can only fail in event of hardware failure. I'm pretty confident that other mail servers treat not losing messages as seriously, as losing messages is the most serious (non-security related) bug a mail server can suffer from.
MQSeries cannot offer any more guarantees than this, because it _must_ be as susceptible to hardware failure as the software I worked on. The only way of improving this situation is to run on more reliable hardware, which is orthogonal to the design purposes of the software. I could run the mail server on more reliable hardware. I could run it on triple-redundant raid mirrored disks on a system with two entirely redundant computers kept in sync with each other, with separate power supplies, so that if one fails the other can take over and make sure nothing is lost -- IBM produce such a system, I know, and I see no reason my software couldn't run on it.
If [...] it doesn't matter if your messages can be delivered twice by mistake
It is very simple to add a layer on top of e-mail that ensures no message is delivered twice; you keep a database in your delivery spool of message-ids and don't deliver anything you already have. This isn't something the server I worked on does (it wasn't a design requirement) but it could easily be added. It would also be trivially easy for client software to filter out redundant messages. This seems like a non-problem to me.
By the way, why am I meta-moderating 2 times a day and going for weeks and weeks without ever seeing mod points? What's up with that, did I quote a naughty word or something? I mean, I don't mind, but it's odd... it's been almost a month since I've seen mod points... and meta-moderating 2 times a day, I kid you not...
I've been in this situation for about a year now. Welcome to the mod-ban club. You probably moderated an editor down, or moderated up a message that an editor thought was particularly problematic (possibly because it was insulting to one of them). This happens all the time; it's the slashdot editors' way of thanking us for doing such a conscientious job in moderating their site for them.
It seems that some people also get banned from metamoderating, although I don't know why that happens.
The problem with CORBA is, frankly, that all the documentation on it that I've ever seen is terrifying. To the uninitiated, it seems like a huge mess.
SOAP, however, while it is getting more complicated over time, gives an easy in. It is very simple for somebody to look at the documentation for a SOAP service without knowing anything at all about SOAP and see it for what it is -- I send an XML encoded request in this format, get back an XML encoded response in this format (yes it can be more complicated, but for 90% of services this is all that's required -- for the rest, CORBA's probably better).
And, of course, it's worth noting how little the average geek knows about SOAP.
I've had a few PSUs die, but never had one take out any other components as many people here seem to have done. Guess I've been lucky so far.
I have however (twice) plugged a PC set for 110V AC into a 240V supply. Bang!
23% Bad gear and user negligence
Bought 3 Maxtor hard disks last year, all the same model, all of them died within a month of each other. That sounds like bad gear to me.
13% Heatsink related
Oh, yeah, I buy el-cheapo CPU fans too. Constantly replacing them. Only once have I had a PSU fan fail, BTW, but the results were... amusing. When I opened the PSU case up to do a post-mortem on why the thing had failed it had melted through several cables. I'm lucky it didn't catch fire.
15% Assembly and moving 3% Computer cruelty
Not sure which of these categories these come under, but hey:
I've killed a hard disk by running it resting on top of the case and accidentally shorting out some connections on the exposed circuitry.
I've killed a processor and motherboard by plugging a celeron into a motherboard that just wasn't compatible with it (apparently the pin-outs on celerons changed half way through production; nobody told me this until it was too late!) -- the chip exploded (literally) and took out a fairly large chunk of the motherboard with it.
10% Lightning strike and static 6% USB related 2% Overclocking
I know this, my employer is currently in the process of taking a great GPL'd application and customizing it quite extensively for themselves (many man-years of work). And you know what? It isn't helping anybody else.
Are you sure it isn't? Does anyone outside of the company know that this is what you're doing? If so, it may encourage somebody else to start using the same GPL software.
User base is critical for many types of software because of the network effect -- people will not start using a particular piece of software if they think not many other people are using it because they worry that it'll be harder to get support for it, because they think that it will be tricky to use when dealing with other people who use different software.
That code will never ever see the light of day outside the company.
And if they didn't do it this way, what difference would that make?
The point is that the GPL has given them the freedom to do it, and that was the original idea behind the GPL. Not to force them to release any modification they make, but to strike a middle ground between individual freedom and the need for the community to benefit.
Even inside the company, source to the modifications is closely held due to internal politics. We are riding on the work of the awesome volunteers who put in their work for free, and we have no intention of giving anything back, ever.
There are many ways of giving back. Just let those original authors know what you're doing with their work, and thank them for it. I'm sure they'll appreciate that.
Meanwhile, thousands of people may end up with copies of the program, but be forbidden to share it with anybody and unable to access the source. This is exactly the situation the GPL was supposed to prevent! If this is how corporations adopt GPL software, I say why bother letting them adopt it at all?
However, I doubt that PublishAmerica will loose any reputation among serious people in the publishing industry because of this.
Well, true, but it is drawing the popular media's attention to what they do. So the average writer, who isn't a publishing industry insider, is more likely to be cautious when dealing with them. This can only be a good thing.
What is half baked? This is exactly the business model that MySQL uses with their database drivers. The MySQL server may be free, but you still have to LINK a MySQL driver to your program. Since the driver is GPL (but NOT LGPL) you can only link a GPL'ed program, or buy a commercial license.
Interestingly, it doesn't actually work, legally speaking for MySQL. Here's the problem:
Say I write a program that uses a standardised interface to communicate with a database. I could choose ODBC, JDBC or ADO.NET, all of which MySQL provide GPL drivers for. Because there is an abstraction layer between my program and the driver my code is _not_ legally a derivitive work of the driver. It's a derivitive work of the abstraction layer. The abstraction layer was written with no knowledge of the MySQL driver, so it clearly can't be a derivitive work either. So, legally, there is no way that MySQL can restrict distribution of either of these parts.
Now, if I distribute my code linked with the driver then clearly my code would have to be distributed under the GPL, but as none of these abstraction layers require that, all I have to do is distribute them together in separate archive files, and the GPL 'mere aggregation on a storage medium' clause applies. No GPL on my app.
Fortunately for trolltech, this isn't a problem that applies to them.
It sucks, but that's the GPL as it stands. I think this is a HUGE loophole in the GPL, and it should definitely be closed in GPL v3. The code should always be licensed to individuals, never corporations.
This fact is critical to corporate adoption of GPL software. Without it, it would be impossible for a company to make internal modifications to GPL software, a right which individual users have. Corporations aren't going to want to get involved if they have less rights than individuals.
Mono demonstrates the problems faced in porting.NET to other platforms. Mono must literally pull in the whole winelib in order to cope with the number of tainted.NET apps that attempt to call out to Win32. And too bad if you're running Mono on a non-x86, non-Linux system since winelib is x86 only (for now).
I'm not really an expert on.NET programming (I've written a couple of desktop apps and played around a little more extensively with ASP.NET), but I understood the problem to be that the Windows.Forms API was designed directly around the Win32 API and exposes some behaviours of that API that are too tricky to implement without using winelib (such as the Form.DefWndProc method, to which unprocessed events are passed in native Win32 format). No need to use unsafe code to require the use of winelib -- this is a showstopper right here, defined within the framework.
And too bad if you're running Mono on a non-x86, non-Linux system since winelib is x86 only (for now).
"You can also build Winelib and Winelib applications on platforms not supported by Wine, typically platforms with a non i386 processor."
http://www.winehq.org/site/docs/winelib-user/win el ib-requirements
Perhaps if Mono gains momentum it might put the brakes on tainted code
As I say, nothing needs to be tainted for it to be a problem. What needs to happen is for people to stop using Windows.Forms. Entirely. I don't expect that to happen any time soon, whether mono takes off or not.
Yes Java supports C++ native calls, but look at how bloody painful it is to do it. You have to define an interface, run it through a stub compiler, implement the stubs and use helpers to marshal types back and forth between C++ and their Java equivalents. It involves lots of files and lots of fiddling about.
You seem to be confusing JNI with the old unstandardised Java 1.0 mechanism. There is no need for stub compilers and type marshalling any more. You just write your code to access the Java data directly, using the provided methods to convert strings and arrays to C++-accessible data or vice versa when you need to access or modify them.
Having written a type library with about 10,000 lines of JNI code, I can tell you that it isn't really all that difficult.
You seem to have missed the entire point of this article, which is that.NET's unmanaged code facilities are no worse than Java's JNI. Which is probably true. Both allow you to interface unsafe code with safe, but the use of both is disallowed by the environment you typically run untrusted code in when using the platform.
Mac users are demanding and impatient. All that typical slowness you see logging in, opening apps, closing windows, etc., with no feedback on XP makes Mac users want to pluck their eyes out.
Strangely, I don't see it. All of these actions give perfectly adequate feedback. Logging in, the screen clears and you get an hourglass until the desktop appears (which typically takes about 1-2 seconds, unless there are network connections to reestablish, in which case a dialog appears telling you what is happening). Opening apps, the mouse cursor changes to the 'background processing' cursor to indicate that something is happening until the first window appears. Closing windows it is up to the application to provide feedback, but most either close the window instantly or provide an hourglass while it is happening (this will happen automatically if the application is not responding to messages).
There is no shortage of feedback in Windows; it's just more subtle than the feedback you get from OSX.
How are non-geographic (e.g. 1-800) numbers routed? Could a similar system not be used to that to provide portability of any number?
(I know in the UK numbers must, legally speaking, be portable between any provider operating in the same area, and that some providers can take a number that's mapped onto their exchange and terminate it anywhere they want, but I'm not sure of the details of how it works or whether a similar system is available in the US)
Here in the UK you can now relatively easily get VOIP terminated phone numbers but only in the area code where you live (you need a billing address there).
You can get VOIP numbers in pretty much any area from a number of suppliers. I don't have the details now, but a colleague of mine has a London terminated number which he uses from our office in Warwick. Or would do, if we could get the damned thing to work through an NAT-ing firewall.
I've said it before and I'll say it again. No P2P software can hide the downloader's IP address, except by using proxies as the post you were replying to suggests. This is a simple fundamental fact of Internet networking -- you _cannot_ send data to an Internet user without knowing their IP address. The fact that the BitTorrent software displays this while [insert favourite 'stealth' p2p app] doesn't is irrelevant. You can easily get those addresses in the other software by installing a packet sniffer on your local network. Therefore repeated requests to P2P client authors to hide addresses in the UI is counterproductive -- doing so will only give users a false sense of security.
Slashdot Mirror
Did you miss the story about them opening the schema for WordML up? You're playing right into his hands if you ask that question...
Microsoft's "Get the facts" campaing has been highly publicised in a wide variety of places, and frequently cites figures from studies that seem to show Windows at an advantage over Linux, yet on careful examination of these studies there are often methodological flaws in them.
I recall reading the details of one from the downloadable report on the Microsoft web site recently that compared the throughput of Windows + IIS to Linux + Apache for serving static web pages. The figures showed Windows in a clear lead, yet on closer examination it appears that the Windows installation had been thoroughly optimised (by, e.g., turning off the collection of last access information on the file system and increasing the default filesystem block size, see pages 30 & 33 of the document linked) whereas similar optimisations had not been applied to the Linux system for the test (with default configurations suggested by the distribution installer accepted for filesystem parameters, see pages 30 - 32 of the document).
How would you answer those who are concerned that by presenting these "independent" tests where the testers have followed precise instructions from Microsoft on how to optimise their products but have not (apparently) consulted Linux experts on how to optimise Linux systems as authoritative that you are unfairly distorting the truth and painting a poor picture of Linux? Is it just that you're doing your job the only way you can, because on a level playing field Linux would win? Or is the picture of these reports as unfair to Linux in some way wrong?
PHP is good for web programming
/var/www/acmqueue.com/htdocs/db/db.php on line 88
Tell that to ACM:
Fatal error: Call to undefined function: message_die() in
It's also the figure equivalent to the figure that was quoted in the grandparent article that he was comparing it to (from the 'VIRT' column of the output of top(1)), so would be the best figure to use for that purpose.
Somewhere in IBM's headquarters there is a camel. A straw has just been placed on its back.
Nah, this is IBM. There's two camels, so that if one of them falls over the other can carry the load temporarily while they arrange a replacement.
Except that most mail servers aren't designed to give the kind of delivery guarantees that message queueing software like MQSeries does.
Aren't they? I've worked on mail server software, and the primary design goal of that server was this:
Never lose a message if you've sent the confirmation that it has been received.
The techniques we used to achieve this (a journal of all incoming messages with a record of where they were delivered, so that undelivered messages can be reconstructed in event of failure) are all well known and thoroughly audited and tested, and can only fail in event of hardware failure. I'm pretty confident that other mail servers treat not losing messages as seriously, as losing messages is the most serious (non-security related) bug a mail server can suffer from.
MQSeries cannot offer any more guarantees than this, because it _must_ be as susceptible to hardware failure as the software I worked on. The only way of improving this situation is to run on more reliable hardware, which is orthogonal to the design purposes of the software. I could run the mail server on more reliable hardware. I could run it on triple-redundant raid mirrored disks on a system with two entirely redundant computers kept in sync with each other, with separate power supplies, so that if one fails the other can take over and make sure nothing is lost -- IBM produce such a system, I know, and I see no reason my software couldn't run on it.
If [...] it doesn't matter if your messages can be delivered twice by mistake
It is very simple to add a layer on top of e-mail that ensures no message is delivered twice; you keep a database in your delivery spool of message-ids and don't deliver anything you already have. This isn't something the server I worked on does (it wasn't a design requirement) but it could easily be added. It would also be trivially easy for client software to filter out redundant messages. This seems like a non-problem to me.
By the way, why am I meta-moderating 2 times a day and going for weeks and weeks without ever seeing mod points? What's up with that, did I quote a naughty word or something? I mean, I don't mind, but it's odd... it's been almost a month since I've seen mod points... and meta-moderating 2 times a day, I kid you not...
I've been in this situation for about a year now. Welcome to the mod-ban club. You probably moderated an editor down, or moderated up a message that an editor thought was particularly problematic (possibly because it was insulting to one of them). This happens all the time; it's the slashdot editors' way of thanking us for doing such a conscientious job in moderating their site for them.
It seems that some people also get banned from metamoderating, although I don't know why that happens.
Damn you!
The problem with CORBA is, frankly, that all the documentation on it that I've ever seen is terrifying. To the uninitiated, it seems like a huge mess.
SOAP, however, while it is getting more complicated over time, gives an easy in. It is very simple for somebody to look at the documentation for a SOAP service without knowing anything at all about SOAP and see it for what it is -- I send an XML encoded request in this format, get back an XML encoded response in this format (yes it can be more complicated, but for 90% of services this is all that's required -- for the rest, CORBA's probably better).
And, of course, it's worth noting how little the average geek knows about SOAP.
My stories.
26% PSU and power issues
I've had a few PSUs die, but never had one take out any other components as many people here seem to have done. Guess I've been lucky so far.
I have however (twice) plugged a PC set for 110V AC into a 240V supply. Bang!
23% Bad gear and user negligence
Bought 3 Maxtor hard disks last year, all the same model, all of them died within a month of each other. That sounds like bad gear to me.
13% Heatsink related
Oh, yeah, I buy el-cheapo CPU fans too. Constantly replacing them. Only once have I had a PSU fan fail, BTW, but the results were... amusing. When I opened the PSU case up to do a post-mortem on why the thing had failed it had melted through several cables. I'm lucky it didn't catch fire.
15% Assembly and moving
3% Computer cruelty
Not sure which of these categories these come under, but hey:
I've killed a hard disk by running it resting on top of the case and accidentally shorting out some connections on the exposed circuitry.
I've killed a processor and motherboard by plugging a celeron into a motherboard that just wasn't compatible with it (apparently the pin-outs on celerons changed half way through production; nobody told me this until it was too late!) -- the chip exploded (literally) and took out a fairly large chunk of the motherboard with it.
10% Lightning strike and static
6% USB related
2% Overclocking
Never (knowingly) had any of these.
I know this, my employer is currently in the process of taking a great GPL'd application and customizing it quite extensively for themselves (many man-years of work). And you know what? It isn't helping anybody else.
Are you sure it isn't? Does anyone outside of the company know that this is what you're doing? If so, it may encourage somebody else to start using the same GPL software.
User base is critical for many types of software because of the network effect -- people will not start using a particular piece of software if they think not many other people are using it because they worry that it'll be harder to get support for it, because they think that it will be tricky to use when dealing with other people who use different software.
That code will never ever see the light of day outside the company.
And if they didn't do it this way, what difference would that make?
The point is that the GPL has given them the freedom to do it, and that was the original idea behind the GPL. Not to force them to release any modification they make, but to strike a middle ground between individual freedom and the need for the community to benefit.
Even inside the company, source to the modifications is closely held due to internal politics. We are riding on the work of the awesome volunteers who put in their work for free, and we have no intention of giving anything back, ever.
There are many ways of giving back. Just let those original authors know what you're doing with their work, and thank them for it. I'm sure they'll appreciate that.
Meanwhile, thousands of people may end up with copies of the program, but be forbidden to share it with anybody and unable to access the source. This is exactly the situation the GPL was supposed to prevent! If this is how corporations adopt GPL software, I say why bother letting them adopt it at all?
Why prevent them? What do you gain by doing so?
However, I doubt that PublishAmerica will loose any reputation among serious people in the publishing industry because of this.
Well, true, but it is drawing the popular media's attention to what they do. So the average writer, who isn't a publishing industry insider, is more likely to be cautious when dealing with them. This can only be a good thing.
What is half baked? This is exactly the business model that MySQL uses with their database drivers. The MySQL server may be free, but you still have to LINK a MySQL driver to your program. Since the driver is GPL (but NOT LGPL) you can only link a GPL'ed program, or buy a commercial license.
Interestingly, it doesn't actually work, legally speaking for MySQL. Here's the problem:
Say I write a program that uses a standardised interface to communicate with a database. I could choose ODBC, JDBC or ADO.NET, all of which MySQL provide GPL drivers for. Because there is an abstraction layer between my program and the driver my code is _not_ legally a derivitive work of the driver. It's a derivitive work of the abstraction layer. The abstraction layer was written with no knowledge of the MySQL driver, so it clearly can't be a derivitive work either. So, legally, there is no way that MySQL can restrict distribution of either of these parts.
Now, if I distribute my code linked with the driver then clearly my code would have to be distributed under the GPL, but as none of these abstraction layers require that, all I have to do is distribute them together in separate archive files, and the GPL 'mere aggregation on a storage medium' clause applies. No GPL on my app.
Fortunately for trolltech, this isn't a problem that applies to them.
It sucks, but that's the GPL as it stands. I think this is a HUGE loophole in the GPL, and it should definitely be closed in GPL v3. The code should always be licensed to individuals, never corporations.
This fact is critical to corporate adoption of GPL software. Without it, it would be impossible for a company to make internal modifications to GPL software, a right which individual users have. Corporations aren't going to want to get involved if they have less rights than individuals.
The nice thing about altivec is that it has a C interface. You don't have to use assembly!
MS's compilers have a similar interface to MMX/SSE. I think the advantage of this project is that it's an abstraction layer that can use either.
Your list misses:
3DNow! (AMD-x86): 8 byte registers, single precision floats
Possibly a footnote of history now, but worth mentioning as a fairly significant proportion of processors support it.
One of the biggest flaws in MMX/SSE that I found was the lack of instructions to shuffle data around within a (8-byte or 16-byte) register.
You mean like the PSHUF* family of instructions? Or something else?
Mono demonstrates the problems faced in porting .NET to other platforms. Mono must literally pull in the whole winelib in order to cope with the number of tainted .NET apps that attempt to call out to Win32. And too bad if you're running Mono on a non-x86, non-Linux system since winelib is x86 only (for now).
.NET programming (I've written a couple of desktop apps and played around a little more extensively with ASP.NET), but I understood the problem to be that the Windows.Forms API was designed directly around the Win32 API and exposes some behaviours of that API that are too tricky to implement without using winelib (such as the Form.DefWndProc method, to which unprocessed events are passed in native Win32 format). No need to use unsafe code to require the use of winelib -- this is a showstopper right here, defined within the framework.
n el ib-requirements
I'm not really an expert on
And too bad if you're running Mono on a non-x86, non-Linux system since winelib is x86 only (for now).
"You can also build Winelib and Winelib applications on platforms not supported by Wine, typically platforms with a non i386 processor."
http://www.winehq.org/site/docs/winelib-user/wi
Perhaps if Mono gains momentum it might put the brakes on tainted code
As I say, nothing needs to be tainted for it to be a problem. What needs to happen is for people to stop using Windows.Forms. Entirely. I don't expect that to happen any time soon, whether mono takes off or not.
Yes Java supports C++ native calls, but look at how bloody painful it is to do it. You have to define an interface, run it through a stub compiler, implement the stubs and use helpers to marshal types back and forth between C++ and their Java equivalents. It involves lots of files and lots of fiddling about.
You seem to be confusing JNI with the old unstandardised Java 1.0 mechanism. There is no need for stub compilers and type marshalling any more. You just write your code to access the Java data directly, using the provided methods to convert strings and arrays to C++-accessible data or vice versa when you need to access or modify them.
Having written a type library with about 10,000 lines of JNI code, I can tell you that it isn't really all that difficult.
You seem to have missed the entire point of this article, which is that .NET's unmanaged code facilities are no worse than Java's JNI. Which is probably true. Both allow you to interface unsafe code with safe, but the use of both is disallowed by the environment you typically run untrusted code in when using the platform.
I fail to see the problem.
I am not using .NET because I don't want to tie myself to Microsoft platforms.
.NET platform, that's a daft argument.
Seeing as there are non-MS implementations of almost all of the
Mac users are demanding and impatient. All that typical slowness you see logging in, opening apps, closing windows, etc., with no feedback on XP makes Mac users want to pluck their eyes out.
Strangely, I don't see it. All of these actions give perfectly adequate feedback. Logging in, the screen clears and you get an hourglass until the desktop appears (which typically takes about 1-2 seconds, unless there are network connections to reestablish, in which case a dialog appears telling you what is happening). Opening apps, the mouse cursor changes to the 'background processing' cursor to indicate that something is happening until the first window appears. Closing windows it is up to the application to provide feedback, but most either close the window instantly or provide an hourglass while it is happening (this will happen automatically if the application is not responding to messages).
There is no shortage of feedback in Windows; it's just more subtle than the feedback you get from OSX.
Is that mem usage (paged in memory) or VM size (a more realistic figure of memory usage)?
How are non-geographic (e.g. 1-800) numbers routed? Could a similar system not be used to that to provide portability of any number?
(I know in the UK numbers must, legally speaking, be portable between any provider operating in the same area, and that some providers can take a number that's mapped onto their exchange and terminate it anywhere they want, but I'm not sure of the details of how it works or whether a similar system is available in the US)
Here in the UK you can now relatively easily get VOIP terminated phone numbers but only in the area code where you live (you need a billing address there).
You can get VOIP numbers in pretty much any area from a number of suppliers. I don't have the details now, but a colleague of mine has a London terminated number which he uses from our office in Warwick. Or would do, if we could get the damned thing to work through an NAT-ing firewall.
I've said it before and I'll say it again. No P2P software can hide the downloader's IP address, except by using proxies as the post you were replying to suggests. This is a simple fundamental fact of Internet networking -- you _cannot_ send data to an Internet user without knowing their IP address. The fact that the BitTorrent software displays this while [insert favourite 'stealth' p2p app] doesn't is irrelevant. You can easily get those addresses in the other software by installing a packet sniffer on your local network. Therefore repeated requests to P2P client authors to hide addresses in the UI is counterproductive -- doing so will only give users a false sense of security.