There's already a client/server framework available where most of the work is done by the server (it has the widget set instead), so the amount of data sent to it is small by comparison with X. It's called picogui.
Needing 100 Mb/s or Gb/s of bandwidth to run X clients over network means X is barely suitable for cable modem or DSL, and then only for the basic stuff (8 bit color, small resolution, no obliquewindows moving). And by the way, it sucks in 24 or 32 bit color depth even on 100 Mb/s network. Try it.
Network transparency itself is not a problem where you need it. Neither is the flexible client-server model. Bandwidth requirements is a problem however. As I pointed out, running X across a network is sloooow because it needs to send so much data with resolutions and color depths most people use these days.
Such large increase shouldn't be there. It's a design flaw. There are (incompatible of course), solutions available which take bandwidth into consideration.
Has already happened in NetBSD CURRENT. Their implementation obviates the need for sendfile() for zero copy if the program is structured to allow the kernel to do it through page loaning.
Have you cosidered other equipment, or are you biased towards Cisco? I know some people who are blind to better products because for some reason they're committed to buying from Cisco only.
I am sure having a nice BSD IPV6 box as one of your routers wouldn't hurt your network.
You're confused. An SMTP client doesn't necessarily mean a user's MUA. Your SMTP server receives email from SMTP relays, which are usually not MUAs (and shouldn't be, since MUAs' job is to pass email to an SMTP relay, not handle it by itself).
You could easily run a service along with SMTP on a different port. This is how it's done with Qmail for example. The new service is advertized through MX records with special distance values. If a remote client supports the new transfer protocol, the MX record will tell it that your server runs this alternate protocol.
It would be up to the end-user to charge or not, the amount, and whether to credit if the email is not SPAM. Those looking to set up a lucrative business of the future, start now - ISP banks.
It seems the only truely effective way to prevent SPAM is to charge for it. So far every technological SPAM blocking technique has failed to completely protect against it. It's just a matter of time before spammers find a way around any new technological solutions possible.
The end-user will be in charge of debiting the sender. If a stranger sender is told that he must pay, but will be credited if it's not SPAM, the SPAM problem is solved. Rich spammers can spam me all they want for ten dollars a piece.
Slashdot Mirror
http://fefe.de/dietlibc/
Uf you're not familiar yet, see PicoGUI for an insight how they do things differently.
There's already a client/server framework available where most of the work is done by the server (it has the widget set instead), so the amount of data sent to it is small by comparison with X. It's called picogui.
I suppose it's possible to write X compatible libraries for running X clients without the server. How many man decades would this take, heh?
You obivously don't know that LBX doesn't help much. It's downright useless.
Needing 100 Mb/s or Gb/s of bandwidth to run X clients over network means X is barely suitable for cable modem or DSL, and then only for the basic stuff (8 bit color, small resolution, no obliquewindows moving). And by the way, it sucks in 24 or 32 bit color depth even on 100 Mb/s network. Try it.
LBX is dead, it doesn't help much. Just increases latency.
Network transparency itself is not a problem where you need it. Neither is the flexible client-server model. Bandwidth requirements is a problem however. As I pointed out, running X across a network is sloooow because it needs to send so much data with resolutions and color depths most people use these days.
Sarcasm aside, recognizing what really sucks is a good idea. NFS and AFS, termcap, lpr, lprn-ng do belong to that list. Oh, C++ also of course.
Large amounts of data sent across the network when you run clients across the network instead of the same machine. This is what X was designed for.
Such large increase shouldn't be there. It's a design flaw. There are (incompatible of course), solutions available which take bandwidth into consideration.
And have you _ever_ thought about not having knee-jerk reactions? The issue here is needlessly large amounts of data sent over the network.
Emphasis on chatty. X is accelerated, it's just overly bandwidth hungry among other things.
Has already happened in NetBSD CURRENT. Their implementation obviates the need for sendfile() for zero copy if the program is structured to allow the kernel to do it through page loaning.
Have you cosidered other equipment, or are you biased towards Cisco? I know some people who are blind to better products because for some reason they're committed to buying from Cisco only.
I am sure having a nice BSD IPV6 box as one of your routers wouldn't hurt your network.
You're confused. An SMTP client doesn't necessarily mean a user's MUA. Your SMTP server receives email from SMTP relays, which are usually not MUAs (and shouldn't be, since MUAs' job is to pass email to an SMTP relay, not handle it by itself).
The non-paying senders' email will be bounced if the receivers decide to charge for it.
The reciever charges you, if you don't pay the message doesn't get through.
The recepient would charge for email, not a centralized authority.
You could easily run a service along with SMTP on a different port. This is how it's done with Qmail for example. The new service is advertized through MX records with special distance values. If a remote client supports the new transfer protocol, the MX record will tell it that your server runs this alternate protocol.
ISPs could simply become small online banks. Not a big deal.
http://cr.yp.to/im2000.html
It would be up to the end-user to charge or not, the amount, and whether to credit if the email is not SPAM. Those looking to set up a lucrative business of the future, start now - ISP banks.
It seems the only truely effective way to prevent SPAM is to charge for it. So far every technological SPAM blocking technique has failed to completely protect against it. It's just a matter of time before spammers find a way around any new technological solutions possible.
The end-user will be in charge of debiting the sender. If a stranger sender is told that he must pay, but will be credited if it's not SPAM, the SPAM problem is solved. Rich spammers can spam me all they want for ten dollars a piece.
Join the IM2000 mailing list.
http://cr.yp.to/im2000.html