In most US states (and many other countries), the legal concept of "priest-penitent priviledge" means that a religious professional cannot be compelled to testify about confidential matters learned in the course of his duties.
It is similar to the privileges enjoyed by attorneys, physicians, and spouses. The legal argument (first successfully used in US court in 1813) is that "freedom of religion" requires barring the government from interfering in a religion's practice of private confession.
(Here's an informative counterargument to the prevailing Constitutional interpretation)
The lack of Turing completeness will be an useful feature of a protocol like that.
Eventually those same paranoid companies who run tight firewalls will get burned by application exploits over SOAP/XML-RPC, and will want all HTTP traffic cleansed for their safety.
As long as the messages are non-TC (meaning their results can be evaluated in a reasonably bounded time), it will be possible for proxy rules to be added to permit some GUI traffic. Otherwise, reactionary IT directors will want to ban it entirely.
* It requires that incoming mail be able to generate a financial transaction. Picture the exchange exploit of the month having access to an electronic payment system. Oh baby, those are going to be some rich script kiddies!
I hope so- it might drive Microsoft out of the server space once and for all.
However, we actually wouldn't get rich script kiddies- just jailed ones. Transactions leave trails. Maybe they can root the mail server and clean their tracks (although kiddies don't usually bother, if they even know how), but compromising the micropayment server and/or the creditcard company will be a different magnitude of challenge.
It's the "don't come into my neighborhood unless you pay at the gate" approach, and that creates closed communities.
We have those communities today. Downtown London, for instance. They're still public places- anyone can get in with a 10 note. A true suburban-royalty "Gated Community", on the other hand, says "don't come in unless you're on the list". Strangers have no opportunity to pass through at all, no matter how much they need or want to. This is less fair, and less inclusive.
If nothing else is done to stop spam, we'll see people start to auto-drop anything not on their friends&family&coworkers whitelist.
All of those products will be the ones that fill your inbox as soon as micro-payments make it seem less like a den of hustlers and degenerates.
A marginal improvement, then. And if you don't like it, dial the value up more and more.
Micropayment email isn't an alternative to crypto solutions which confirm senders' identities- it's a backup, a backdoor. (After all, confirmed identities is a prerequistite for implementing the money exchange). If any system is created which locks out unsolicited email from strangers, you may miss out on some communications (stereotypically a high-school sweetheart) that you would rather have gotten. Even if the price was $5 (macropayment?), email fees would allow dedicated individuals to reach you in an emergency, preventing corporations from feeding their grinders.
By the tenets of capitalism, the best and fairest way to prevent abuse of a free resource is to "internalize the costs".
law that calls for legitimate and accurate headers on all e-mail?
Internet users value the possibility of anonymity.
Better than a law to enforce accurate headers would be a technical solution- altered mail clients/servers which permit a user, at her option, to automatically disgard messages without a return address signed by a trusted authority (business opportunity?)
Allowing government regulators to get tightly coupled with mail-server enforcement would cause many of the same problems taxation would- beaureacratic overhead, compliance audits, etc. And once mail servers were monitored, it would be easier later on for the Feds to start taxing.
For starters, by charging someone a fee, you implicitly accept a number of responsibilities for the prodcut or service.
The software industry has a successful tradition of easily disclaiming any liablity regardless of charging huge fees.
No not at all, but who's going to pay $0.25 to ANSWER? No one of course, so only private replies will be sent, but even then it's goign to cost SOMETHING.
The regular users would have whitelisted accounts permitting them to send messages to it without paying.
The core of the "micropayment personal email stamp" proposal is that payments are configured by the individual recipient, including the possiblity of not charging different amounts to set patterns of sender address.
If such a system turns out to be inapplicable to large mailing lists (because they fan out to hundreds of readers, making even a heavy fee profitable for spammers), then the ML admins can simply set their email charge to $0, and be in exactly the same situation they are now.
But a micropayment-based system could still serve to protect individual accounts. It's not a flag-day; there's no need to replace existing SMTP mailers in one big, incompatible swoop.
Obviously, the transaction would be between just two endpoints. That's how existing SMTP works. Sending to a mailing list is just a single recipient (who happens to be a robot which will automatically forward to many others, engaging in it's own transactions with them, and generally skipping anyone who won't accept the message for free).
The admin of the mailing list can set any price he desires to post to it. Since an ML is a recipient multiplier and a fat target for spam, they might choose $0.20 or $0.50 for a message. Of course, users can register as a poster to have fees waived for sending to an ML address (allow anyone to subscribe to recieved automatically. Subscribing to post for free takes either the admin or an existing subscriber sending you an invite, which'll prevent automated joining by spamware).
And $0.25 isn't too much for a non-subscriber who wants driver help from linux-kernel. It might even help keep down the noise from those guys who are wondering why RedHat 9 can't play MP3.
What you're essentially saying is that it is the job of government to redistribute wealth and make it 'fair' for everyone else.
Like it or not, that is the behavior of every major government, including the US. He "essentially said" a simple, observable fact.
here in States we have a system that was setup on 'equal opportunity', not 'equal outcome'.
Property taxes are primarily collected by local governments, and the largest expenditure of local governments is public education, which directly supports the "Equal Opportunity" goal.
Government redistribution of wealth through taxes is socialism, pure and simple.
It might more accurately be termed "kleptocracy". "Socialism" is too specific.
It means that people will actually stop sending smaller email
More likely, they'd start sending really big Instant Messages.
And then, AIM's programmers would puff up it's features with things like "Buffer until recipient is online", to emulate the feel of old-fashioned email as much as possible, without actually meeting the legal definition and becoming taxable.
Micropayments would actually be a good part of an excellent solution to spam.
The FT author is correct that a tiny per-message cost would wipe out the spamming business, while being unnoticable to normal users. But the best way to implement a system like that is not through a tax by the government- but by a voluntary charge set by each recipient. (The sender is apprised of the fee when transmitting, and has the option to either pay up, or abort the message)
If everyone charged $0.01 to (or as much as $0.25) to get an email, then spammers would go out of business, but friends engaging in back & forth correspondence will balance out with each other. And, mailing-lists should be able to instruct subscribers on how to white-list ML correspondence, so that it's permitted with no fee.
This scheme is permissive, and some amount of unsolicited commercial mail might still occur (only if it is relatively targeted, and thus much more likely to produce an inquiry). But cutting out 97% of spam would be a good help.
(Of course, either this solution or the taxation one would require difficult technical changes to the email protocol, and of course there'd first have to exist a viable micropayment service)
The GPL-relevant difference comes not from "distribution", but who the recipients of the distribution were.
The word "distribute" means to spread something out of physical space. If a business mails boxes to 10 different customers, the English language definition of distribution is clearly met. If a another business installs 2 copies on their co-located servers, that's also "distribution"- but the recipients are their own employees.
According to the GPL, it is those recipients who must get written offers for the source code. Employees are much less likely to invoke that offer than customers.
You can claim it as your own and can do whatever you like but so can everyone else.
It's still dangerous to claim PD material as your own. Yes, you own a nonexclusive copyright to it, and don't need to credit the author in any way. But to claim you are the author is dishonest, and can get you expelled/fired for plagiarism. Or exposed to civil liability, and maybe even arrested for fraud (a big stretch).
Maybe. But since my build came out of a shrinkwrapped box of what is probably the most popular Linux distribution, this could explain where all those complaints of OpenOffice's slowness come from.
It is just the X server and it is perfectly acceptable for running GNOME.
Unless you've also got much newer graphics card, I doubt that many people would enjoy the resolution you must be at.
XFree86 isn't consuming all your RAM and CPU.
I never claimed anything like that. A program can be placing a light load on system resources, and yet take excessive time to respond to user input. (It's analogous to bandwidth versus latency)
In my experience of the response time to draw a pulldown menu in various toolkits, from fastest to slowest they are
XUL
MS Windows
Qt (with a minimalist theme)
Motif
GTK
The fact that Mozilla's XUL was quickest shows that X11 isn't hopeless- but it suggests that the effort to make it speedy is more than most toolkit (or application?) authors are willing to go through.
Though you may need some programming experience to profile XFree86 and GNOME (not trivial).
I do have a few decades of C/C++ experience on my resume... however, sorting through the CORBA-interlocking GNOME processes to profile it would be very time consuming. KDE's much more attractive anyway (at least it supplies a dialog box to select a filename).
Anyway, my boss comes by and asks for some information. I bring it up by opening a Konqueror file manager window to an NFS mount, then opening the file in OpenOffice. He thanked me, then remarked how much snappier my desktop was than his. Huh? That was NFS plus OpenOffice, in case you didn't notice. Everyone on Slashdot tells me that X/KDE is slower than M$/Windows. They tell me so often that I was starting to believe it.
That's really amazing. The complete opposite of my experience.
I have an AMD Athlon XP 1700 with 768 meg ram and a 64 meg Nvdia Geforce2 card at 1280x1204. OpenOffice is quite simply the most painfully slow applcation I've run.
Suppose I call up a spreadsheet in OpenOffice, maximize it so that 30X60 cells of numbers are displayed, and then switch to an alternate desktop. When I switch back, it takes 25 seconds to redraw the spreadsheet. I can watch each and every row appear individually.
This software was installed from a CD sold by Red Hat. Possibly they picked a bad version, or made configuration mistakes- possibly...
Other programs with similar graphics needs, like Kspread, and Gnumeric, are completely fine by comparison. At least, their redraw delays are too small to quantify with a wristwatch!
One is that the X11 process doesn't have a high priority by default.
To check this, just run "top" and check the "NI" value for XFree86. The Linux distributions that I've seen correctly give XFree86 a -10 priority, comfortably superior to user applications (which are typically 0 or higher).
But the IPC overhead consumes less than 1/100th of 1 percent of the time it takes to draw a window or widget when running locally.
It's not the overhead of IPC that makes a difference when you're reaching for extreme speeds- it's the fact that there's another process involved at all. If the data magically transferred between processes instantly (as shared memory does, and Unix sockets virtually do), the user still won't get a response until the OS gives the other process a timeslice.
The history of the WINE project shows many examples of this effect (here's an old one). They emulate Microsoft Windows(tm) features using two processes: wine (for the application itself) and wineserver (for the Windows(tm) OS features). They use very fast IPC between those processes- but the mere fact that wineserver is a separate process at all means they aren't able to approach the speed of executing in the real Windows(tm) environment, where system calls happen inside the same process.
(Naturally, X11 toolkits make many fewer calls needing server roundtrip than a Windows(tm) application does, as they weren't built under the assumption that those things are free. The example of WINE is just to illustrate that context-switch can be an appreciable overhead, regardless of IPC speed)
Back in the 100MHz Pentium days, I was running FVWM, which was very quick and snappy even on the machines of the day.
I have tried Microsoft Windows 95(tm) and fvwm95 on the same 100mhz Pentium computer with a 16 meg ATI Mach64 card. Opening a popup menu on the Microsoft product took an imperceptible time. The menu produced by clicking the desktop background in fvwm, however, produced a delay that was easily detectable to a human operator (which means it was at least 40 milliseconds)
Let's say gtk+ is ported to X as a module, and the gtk+ libraries are modified to look for this.
After such a drastic change, the entire character of the X11 display system would've been altered. Yes, X11 allows arbitrary extensions to be created (and negotiated between client and server, with the possibility of fallbacks). But just because a system is extensible, it doesn't mean speculation about far-out possible additions is at all relevant to the question of how the system works today.
You bash it.
Re-read my post, and you'll see that "bash" isn't nearly applicable.
I run X11 for hours each day, for work, web-browsing, DVDs (a crime), and even high-speed gaming. But I'm unable to evangelize it to my friends, because it feels to them as if there Mhz dropped 35% when running Xfree86.
On Linux, Doors IPC can be faster than Unix sockets (depending on how you benchmark). Sometimes even just pipes can be faster.
Unix sockets are NOT the same as for example accessing a local drive through an NFS mount on the local server. That does indeed go through networking to the 127.0.0.1 address
In that case, the majority of the slowdown comes not from the TCP/IP stack, but from overhead introduced by the nfs client and server processes (as they perform mappings and safety checks that are pointless for local files)
I have personally experienced applications (RealAudio player) on Microsoft Windows that load files more rapidly from HTTP to 127.0.0.1 than by disk access themselves. (This is attributed to poor application design)
Re:This will kill X in the long term.
on
DRI Comes to DirectFB
·
· Score: 2, Informative
Not necessarily. In the default Sharp install, running Java programs (as one example) will create movable windows that partially obscure programs below them. There is a simple kind of "window manager" behavior going on.
Also, it is completely possible to rearrange file permissions so that Qt on the Zaurus can run as non-root. Why Sharp chose not to do this is difficult to imagine.
Re:Network transparency *already* is a "plug in"
on
DRI Comes to DirectFB
·
· Score: 1
This is the only way to make "network transparency" a "plugin"
Technically, "screen-scraper" systems like VNC also make transparency a plugin (as it's a feature that was considered by neither the designers of the GUI system, or individual applicatiosn).
But of course, they pay a high price in lowered responsiveness.
"As stated earlier, this FAQ deals only with AF_INET sockets."
So it's not the best source for Unix domain sockets. However, Unix sockets ARE NETWORKING, from a software perspective. The same socket.h function calls are invoked for TCP/IP, or unix sockets (or even ipx, x25, and other stuff).
are the most efficient form of IPC on Linux
That's the crux of the common complaint. IPC = "interprocess communication". Some other prominent GUI systems don't require interprocess communication to update the screen, and can provide quicker response with less overhead. IPC will always be slower than system calls with no context switching.
This is a possible reason why Microsoft Windows 98(tm) running on a 100mhz Pentium seems so much snappier for minor UI-interaction tasks (pulling down a menu) than a same-vintage Gnome on identical hardware.
But the days when a long distance phone call meant that a continuous strand of copper had been switched together across the continent are gone. No longer one call = one circuit.
(AT&T has stated that 100% of LD traffic will be TCP/IP by 2010)
That "requirement" was an invention of Lenin and Trotsky.
They attempted (successfully) to redefine Communism away from Marx's idea (which are probably impossible to implement) into something they could work with (which was somewhat possible to implement, but impossible to sustain)
Actually, Microsoft-owned Slate Magazine is running an article claming that Theo deRaadt of OpenBSD has found a way to fix all buffer overflows. The journalist encourages Microsoft to copy it from BSD into Windows.
Not necessarily, anymore. A magazine last year claimed that 2-3% of long distance phone traffic in the US is over TCP/IP. Apparently some companies advertise as long-distance carriers, but instead of using something like AT&T's switched network, they send audio data over the normal, public Internet. Seems they have worse sound quality (and maybe some latency?), but they charge less.
Bonus telephone trivia: The first videoconference was between Herbert Hoover and AT&T president Gifford in 1927.
Slashdot Mirror
In most US states (and many other countries), the legal concept of "priest-penitent priviledge" means that a religious professional cannot be compelled to testify about confidential matters learned in the course of his duties.
It is similar to the privileges enjoyed by attorneys, physicians, and spouses. The legal argument (first successfully used in US court in 1813) is that "freedom of religion" requires barring the government from interfering in a religion's practice of private confession.
(Here's an informative counterargument to the prevailing Constitutional interpretation)
The lack of Turing completeness will be an useful feature of a protocol like that.
Eventually those same paranoid companies who run tight firewalls will get burned by application exploits over SOAP/XML-RPC, and will want all HTTP traffic cleansed for their safety.
As long as the messages are non-TC (meaning their results can be evaluated in a reasonably bounded time), it will be possible for proxy rules to be added to permit some GUI traffic. Otherwise, reactionary IT directors will want to ban it entirely.
* It requires that incoming mail be able to generate a financial transaction. Picture the exchange exploit of the month having access to an electronic payment system. Oh baby, those are going to be some rich script kiddies!
I hope so- it might drive Microsoft out of the server space once and for all.
However, we actually wouldn't get rich script kiddies- just jailed ones. Transactions leave trails. Maybe they can root the mail server and clean their tracks (although kiddies don't usually bother, if they even know how), but compromising the micropayment server and/or the creditcard company will be a different magnitude of challenge.
It's the "don't come into my neighborhood unless you pay at the gate" approach, and that creates closed communities.
We have those communities today. Downtown London, for instance. They're still public places- anyone can get in with a 10 note. A true suburban-royalty "Gated Community", on the other hand, says "don't come in unless you're on the list". Strangers have no opportunity to pass through at all, no matter how much they need or want to. This is less fair, and less inclusive.
If nothing else is done to stop spam, we'll see people start to auto-drop anything not on their friends&family&coworkers whitelist.
All of those products will be the ones that fill your inbox as soon as micro-payments make it seem less like a den of hustlers and degenerates.
A marginal improvement, then. And if you don't like it, dial the value up more and more.
Micropayment email isn't an alternative to crypto solutions which confirm senders' identities- it's a backup, a backdoor. (After all, confirmed identities is a prerequistite for implementing the money exchange). If any system is created which locks out unsolicited email from strangers, you may miss out on some communications (stereotypically a high-school sweetheart) that you would rather have gotten. Even if the price was $5 (macropayment?), email fees would allow dedicated individuals to reach you in an emergency, preventing corporations from feeding their grinders.
By the tenets of capitalism, the best and fairest way to prevent abuse of a free resource is to "internalize the costs".
law that calls for legitimate and accurate headers on all e-mail?
Internet users value the possibility of anonymity.
Better than a law to enforce accurate headers would be a technical solution- altered mail clients/servers which permit a user, at her option, to automatically disgard messages without a return address signed by a trusted authority (business opportunity?)
Allowing government regulators to get tightly coupled with mail-server enforcement would cause many of the same problems taxation would- beaureacratic overhead, compliance audits, etc. And once mail servers were monitored, it would be easier later on for the Feds to start taxing.
For starters, by charging someone a fee, you implicitly accept a number of responsibilities for the prodcut or service.
The software industry has a successful tradition of easily disclaiming any liablity regardless of charging huge fees.
No not at all, but who's going to pay $0.25 to ANSWER? No one of course, so only private replies will be sent, but even then it's goign to cost SOMETHING.
The regular users would have whitelisted accounts permitting them to send messages to it without paying.
The core of the "micropayment personal email stamp" proposal is that payments are configured by the individual recipient, including the possiblity of not charging different amounts to set patterns of sender address.
If such a system turns out to be inapplicable to large mailing lists (because they fan out to hundreds of readers, making even a heavy fee profitable for spammers), then the ML admins can simply set their email charge to $0, and be in exactly the same situation they are now.
But a micropayment-based system could still serve to protect individual accounts. It's not a flag-day; there's no need to replace existing SMTP mailers in one big, incompatible swoop.
(much like those novices who confuse RAM and hard disk space and call them both "memory")
What about those experts who know that a hard disk is technically one kind of RAM, and call them both memory?
(The best terms would be [magnetic|electronic] storage)
Obviously, the transaction would be between just two endpoints. That's how existing SMTP works. Sending to a mailing list is just a single recipient (who happens to be a robot which will automatically forward to many others, engaging in it's own transactions with them, and generally skipping anyone who won't accept the message for free).
The admin of the mailing list can set any price he desires to post to it. Since an ML is a recipient multiplier and a fat target for spam, they might choose $0.20 or $0.50 for a message. Of course, users can register as a poster to have fees waived for sending to an ML address (allow anyone to subscribe to recieved automatically. Subscribing to post for free takes either the admin or an existing subscriber sending you an invite, which'll prevent automated joining by spamware).
And $0.25 isn't too much for a non-subscriber who wants driver help from linux-kernel. It might even help keep down the noise from those guys who are wondering why RedHat 9 can't play MP3.
What you're essentially saying is that it is the job of government to redistribute wealth and make it 'fair' for everyone else.
Like it or not, that is the behavior of every major government, including the US. He "essentially said" a simple, observable fact.
here in States we have a system that was setup on 'equal opportunity', not 'equal outcome'.
Property taxes are primarily collected by local governments, and the largest expenditure of local governments is public education, which directly supports the "Equal Opportunity" goal.
Government redistribution of wealth through taxes is socialism, pure and simple.
It might more accurately be termed "kleptocracy". "Socialism" is too specific.
It means that people will actually stop sending smaller email
More likely, they'd start sending really big Instant Messages.
And then, AIM's programmers would puff up it's features with things like "Buffer until recipient is online", to emulate the feel of old-fashioned email as much as possible, without actually meeting the legal definition and becoming taxable.
Micropayments would actually be a good part of an excellent solution to spam.
The FT author is correct that a tiny per-message cost would wipe out the spamming business, while being unnoticable to normal users. But the best way to implement a system like that is not through a tax by the government- but by a voluntary charge set by each recipient. (The sender is apprised of the fee when transmitting, and has the option to either pay up, or abort the message)
If everyone charged $0.01 to (or as much as $0.25) to get an email, then spammers would go out of business, but friends engaging in back & forth correspondence will balance out with each other. And, mailing-lists should be able to instruct subscribers on how to white-list ML correspondence, so that it's permitted with no fee.
This scheme is permissive, and some amount of unsolicited commercial mail might still occur (only if it is relatively targeted, and thus much more likely to produce an inquiry). But cutting out 97% of spam would be a good help.
(Of course, either this solution or the taxation one would require difficult technical changes to the email protocol, and of course there'd first have to exist a viable micropayment service)
The GPL-relevant difference comes not from "distribution", but who the recipients of the distribution were.
The word "distribute" means to spread something out of physical space. If a business mails boxes to 10 different customers, the English language definition of distribution is clearly met. If a another business installs 2 copies on their co-located servers, that's also "distribution"- but the recipients are their own employees.
According to the GPL, it is those recipients who must get written offers for the source code. Employees are much less likely to invoke that offer than customers.
You can claim it as your own and can do whatever you like but so can everyone else.
It's still dangerous to claim PD material as your own. Yes, you own a nonexclusive copyright to it, and don't need to credit the author in any way. But to claim you are the author is dishonest, and can get you expelled/fired for plagiarism. Or exposed to civil liability, and maybe even arrested for fraud (a big stretch).
I suspect that you have a bad build or something.
Maybe. But since my build came out of a shrinkwrapped box of what is probably the most popular Linux distribution, this could explain where all those complaints of OpenOffice's slowness come from.
Unless you've also got much newer graphics card, I doubt that many people would enjoy the resolution you must be at.
XFree86 isn't consuming all your RAM and CPU.
I never claimed anything like that. A program can be placing a light load on system resources, and yet take excessive time to respond to user input. (It's analogous to bandwidth versus latency)
In my experience of the response time to draw a pulldown menu in various toolkits, from fastest to slowest they are
The fact that Mozilla's XUL was quickest shows that X11 isn't hopeless- but it suggests that the effort to make it speedy is more than most toolkit (or application?) authors are willing to go through.
Though you may need some programming experience to profile XFree86 and GNOME (not trivial).
I do have a few decades of C/C++ experience on my resume... however, sorting through the CORBA-interlocking GNOME processes to profile it would be very time consuming. KDE's much more attractive anyway (at least it supplies a dialog box to select a filename).
Anyway, my boss comes by and asks for some information. I bring it up by opening a Konqueror file manager window to an NFS mount, then opening the file in OpenOffice. He thanked me, then remarked how much snappier my desktop was than his. Huh? That was NFS plus OpenOffice, in case you didn't notice. Everyone on Slashdot tells me that X/KDE is slower than M$/Windows. They tell me so often that I was starting to believe it.
That's really amazing. The complete opposite of my experience.
I have an AMD Athlon XP 1700 with 768 meg ram and a 64 meg Nvdia Geforce2 card at 1280x1204. OpenOffice is quite simply the most painfully slow applcation I've run.
Suppose I call up a spreadsheet in OpenOffice, maximize it so that 30X60 cells of numbers are displayed, and then switch to an alternate desktop. When I switch back, it takes 25 seconds to redraw the spreadsheet. I can watch each and every row appear individually.
This software was installed from a CD sold by Red Hat. Possibly they picked a bad version, or made configuration mistakes- possibly...
Other programs with similar graphics needs, like Kspread, and Gnumeric, are completely fine by comparison. At least, their redraw delays are too small to quantify with a wristwatch!
One is that the X11 process doesn't have a high priority by default.
To check this, just run "top" and check the "NI" value for XFree86. The Linux distributions that I've seen correctly give XFree86 a -10 priority, comfortably superior to user applications (which are typically 0 or higher).
But the IPC overhead consumes less than 1/100th of 1 percent of the time it takes to draw a window or widget when running locally.
It's not the overhead of IPC that makes a difference when you're reaching for extreme speeds- it's the fact that there's another process involved at all. If the data magically transferred between processes instantly (as shared memory does, and Unix sockets virtually do), the user still won't get a response until the OS gives the other process a timeslice.
The history of the WINE project shows many examples of this effect (here's an old one). They emulate Microsoft Windows(tm) features using two processes: wine (for the application itself) and wineserver (for the Windows(tm) OS features). They use very fast IPC between those processes- but the mere fact that wineserver is a separate process at all means they aren't able to approach the speed of executing in the real Windows(tm) environment, where system calls happen inside the same process.
(Naturally, X11 toolkits make many fewer calls needing server roundtrip than a Windows(tm) application does, as they weren't built under the assumption that those things are free. The example of WINE is just to illustrate that context-switch can be an appreciable overhead, regardless of IPC speed)
Back in the 100MHz Pentium days, I was running FVWM, which was very quick and snappy even on the machines of the day.
I have tried Microsoft Windows 95(tm) and fvwm95 on the same 100mhz Pentium computer with a 16 meg ATI Mach64 card. Opening a popup menu on the Microsoft product took an imperceptible time. The menu produced by clicking the desktop background in fvwm, however, produced a delay that was easily detectable to a human operator (which means it was at least 40 milliseconds)
Let's say gtk+ is ported to X as a module, and the gtk+ libraries are modified to look for this.
After such a drastic change, the entire character of the X11 display system would've been altered. Yes, X11 allows arbitrary extensions to be created (and negotiated between client and server, with the possibility of fallbacks). But just because a system is extensible, it doesn't mean speculation about far-out possible additions is at all relevant to the question of how the system works today.
You bash it.
Re-read my post, and you'll see that "bash" isn't nearly applicable.
I run X11 for hours each day, for work, web-browsing, DVDs (a crime), and even high-speed gaming. But I'm unable to evangelize it to my friends, because it feels to them as if there Mhz dropped 35% when running Xfree86.
AFAIK, Unix sockets are the fastest form of IPC.
On Linux, Doors IPC can be faster than Unix sockets (depending on how you benchmark). Sometimes even just pipes can be faster.
Unix sockets are NOT the same as for example accessing a local drive through an NFS mount on the local server. That does indeed go through networking to the 127.0.0.1 address
In that case, the majority of the slowdown comes not from the TCP/IP stack, but from overhead introduced by the nfs client and server processes (as they perform mappings and safety checks that are pointless for local files)
I have personally experienced applications (RealAudio player) on Microsoft Windows that load files more rapidly from HTTP to 127.0.0.1 than by disk access themselves. (This is attributed to poor application design)
Not necessarily. In the default Sharp install, running Java programs (as one example) will create movable windows that partially obscure programs below them. There is a simple kind of "window manager" behavior going on.
Also, it is completely possible to rearrange file permissions so that Qt on the Zaurus can run as non-root. Why Sharp chose not to do this is difficult to imagine.
This is the only way to make "network transparency" a "plugin"
Technically, "screen-scraper" systems like VNC also make transparency a plugin (as it's a feature that was considered by neither the designers of the GUI system, or individual applicatiosn).
But of course, they pay a high price in lowered responsiveness.
The link you mention claims
"As stated earlier, this FAQ deals only with AF_INET sockets."
So it's not the best source for Unix domain sockets. However, Unix sockets ARE NETWORKING, from a software perspective. The same socket.h function calls are invoked for TCP/IP, or unix sockets (or even ipx, x25, and other stuff).
are the most efficient form of IPC on Linux
That's the crux of the common complaint. IPC = "interprocess communication". Some other prominent GUI systems don't require interprocess communication to update the screen, and can provide quicker response with less overhead. IPC will always be slower than system calls with no context switching.
This is a possible reason why Microsoft Windows 98(tm) running on a 100mhz Pentium seems so much snappier for minor UI-interaction tasks (pulling down a menu) than a same-vintage Gnome on identical hardware.
HTTP handling in kernel mode... well... maybe they got drunk that day
Other developers have gotten drunk too.
(That is one place where Open Source developers can claim MS is copying their "innovation")
Right, physical circuits for the last mile.
But the days when a long distance phone call meant that a continuous strand of copper had been switched together across the continent are gone. No longer one call = one circuit.
(AT&T has stated that 100% of LD traffic will be TCP/IP by 2010)
Communism REQUIRES a transitional facist period
That "requirement" was an invention of Lenin and Trotsky.
They attempted (successfully) to redefine Communism away from Marx's idea (which are probably impossible to implement) into something they could work with (which was somewhat possible to implement, but impossible to sustain)
Actually, Microsoft-owned Slate Magazine is running an article claming that Theo deRaadt of OpenBSD has found a way to fix all buffer overflows. The journalist encourages Microsoft to copy it from BSD into Windows.
Not necessarily, anymore. A magazine last year claimed that 2-3% of long distance phone traffic in the US is over TCP/IP. Apparently some companies advertise as long-distance carriers, but instead of using something like AT&T's switched network, they send audio data over the normal, public Internet. Seems they have worse sound quality (and maybe some latency?), but they charge less.
Bonus telephone trivia: The first videoconference was between Herbert Hoover and AT&T president Gifford in 1927.