Connect to any server on port 25 (the SMTP port), and fake envelope senders all you want. Cross-subscribe mailing lists all you want. SMTP wasn't designed with authentication and security in mind at all. Furthermore, it is darn slow. Granted it's not SMTP's fault only. It's the architecture's fault. I should have been more generic.
Parsing email messages themselves is a pain in the ass too.
1) Allows senders to be faked. 2) Is slow. 3) Requires bounces for broken messages. 4) Allows loops. 5) Cross-subscription to mailing lists, complicated mailing list management. 6) MIME. 7) Add your gripe here.
How about built-in fault tolerance, distribution, and concurrency (and no stinking dependency on pthreads). Which are all available in a language called Erlang:).
If fork() expense is not an issue, then process context switch and process state memory requirements are definitely issues. Create a few ten thousand processes on your machine, and you'll bring your machine down to its knees. Your memory will be wasted, your CPU will spend most of the time (if not all) context switching.
Of course the solution is a real language with built-in concurrency, message passing, distribution and fault tolerance like Erlang.
Not some perversion like pthreads under Java or pthreads in C. Erlang processes have very lightweight message passing and process management overhead. Lighter than your OS (because all Erlang processes run inside the Erlang VM), several orders of magnitude lighter than Java, and no mutexes, semaphores, and other such bullshit to worry about. In addition you get the ability to distribute your processes seamlessly over networked machines. This is a language built-in feature.
The only library in C which lets you do something similar is state threads from SGI.
No it's just you're brainwashed. Get out of the cult until it's too late. The man behind Falun Gong is a complete con. He's the Chinese version of Church of Scientology.
When writing multithreaded software will be as easy as writing multi-process software, that's where it will be at. Until then, most threaded software is a pain in the ass to write. I say most, because there are libraries which allow for much easier multithreaded software development, without a need for mutexes and locks. e.g.state threads.
Speaking of Java and threads, I think it's past time for someone to seriously think about creating a language with even more first class structures for dealing with parallelism.
Not true. Depends on the application. For example in Opera, paste is done from the X buffer, Mozilla does a paste from it's own buffer. You can't paste from one application's buffer into another in X. In windows, the cut/paste functionality is mostly the same between most if not all apps. Drag and drop is even more pain in the ass, and so are the fonts. Why most, if not all Linux integrators won't care about the fonts still? I can't see how a single font for all apps is great, everywhere, like that freaking helvetica. Having several different methods of cut and paste and drag and drop unleashed on your users, plus the fugly helvetica as a substitute for better fonts as shipped with a Linux distro will lead to major complaints from your users, wouldn't you agree?
Why didn't Linus, Ts'o or someone else just use a different design for the FS layers of the kernel? NetBSD, for example had 64 bit FS support for quite a while (1994). The FS size limit is twice that of the Linux kernel - 4TB. The files can also be terabyte-sized - since 1994!.
Perhaps protecting IT workers so that those skills are cultivated and retained within our country would be useful. Perhaps not, but I'm sorry America is not based solely on free trade, it's based on the interests of its citizens.
You wish. America is primarily interested in profits. Those who have profits, profit. Those who don't, suffer from those who profit from them. Those who stand in the way of making profits will be destroyed. Wake up, amd smell the American Way (TM).
You also have to take in consideration the fact Murdock (sp?) is an uber-conservative right winger. Some of the comments he made on the issue are quite depressing too.
Re:Existing system works - why change?
on
VoIP at $15 a Pop
·
· Score: 1
The savings are in avoiding the bloated monopoly charges for long distance. Internet access is cheaper than international or long distance phone charges. That's why VoIP makes sooo much sense.
Slashdot Mirror
Unless they can't flush well. And most can't, which results in multiple flushings.
Connect to any server on port 25 (the SMTP port), and fake envelope senders all you want. Cross-subscribe mailing lists all you want. SMTP wasn't designed with authentication and security in mind at all. Furthermore, it is darn slow. Granted it's not SMTP's fault only. It's the architecture's fault. I should have been more generic.
Parsing email messages themselves is a pain in the ass too.
SMTP is designed broken because it:
1) Allows senders to be faked.
2) Is slow.
3) Requires bounces for broken messages.
4) Allows loops.
5) Cross-subscription to mailing lists, complicated mailing list management.
6) MIME.
7) Add your gripe here.
See http://cr.yp.to/im2000.html
How about built-in fault tolerance, distribution, and concurrency (and no stinking dependency on pthreads). Which are all available in a language called Erlang :).
What scares most with all these old-time DBs is the cruft they've grown over the years. Complexity. Could somebody testify to its stability?
The mmx and sse optimization do exactly nothing when compiling something like Evolution.
Many, if not most select() and poll() implementations scale very poorly for an order of a few thousand file descriptors.
If fork() expense is not an issue, then process context switch and process state memory requirements are definitely issues. Create a few ten thousand processes on your machine, and you'll bring your machine down to its knees. Your memory will be wasted, your CPU will spend most of the time (if not all) context switching.
Of course the solution is a real language with built-in concurrency, message passing, distribution and fault tolerance like Erlang.
Why Erlang
Not some perversion like pthreads under Java or pthreads in C. Erlang processes have very lightweight message passing and process management overhead. Lighter than your OS (because all Erlang processes run inside the Erlang VM), several orders of magnitude lighter than Java, and no mutexes, semaphores, and other such bullshit to worry about. In addition you get the ability to distribute your processes seamlessly over networked machines. This is a language built-in feature.
The only library in C which lets you do something similar is state threads from SGI.
State Threads
No it's just you're brainwashed. Get out of the cult until it's too late. The man behind Falun Gong is a complete con. He's the Chinese version of Church of Scientology.
Falun Gong is a cult akin to Church of Scientology.
Attempts like this just make encrypted messaging protocols more desired. SMTP is just old, slow, rusty, and stupid. See here: IM2000
I don't wash my hands when I only touch my dick and not the flusher.
You forget GCC and friends, GNU Make, and others.
it makes sense in the cost sense.
When writing multithreaded software will be as easy as writing multi-process software, that's where it will be at. Until then, most threaded software is a pain in the ass to write. I say most, because there are libraries which allow for much easier multithreaded software development, without a need for mutexes and locks. e.g.state threads.
Speaking of Java and threads, I think it's past time for someone to seriously think about creating a language with even more first class structures for dealing with parallelism.
Erlang
Logban http://www.lojban.org/
Not true. Depends on the application. For example in Opera, paste is done from the X buffer, Mozilla does a paste from it's own buffer. You can't paste from one application's buffer into another in X. In windows, the cut/paste functionality is mostly the same between most if not all apps. Drag and drop is even more pain in the ass, and so are the fonts. Why most, if not all Linux integrators won't care about the fonts still? I can't see how a single font for all apps is great, everywhere, like that freaking helvetica. Having several different methods of cut and paste and drag and drop unleashed on your users, plus the fugly helvetica as a substitute for better fonts as shipped with a Linux distro will lead to major complaints from your users, wouldn't you agree?
No, you don't need lots of bandwidth. Especially fo r plasma physics calculations.
Why didn't Linus, Ts'o or someone else just use a different design for the FS layers of the kernel? NetBSD, for example had 64 bit FS support for quite a while (1994). The FS size limit is twice that of the Linux kernel - 4TB. The files can also be terabyte-sized - since 1994!.
Perhaps protecting IT workers so that those skills are cultivated and retained within our country would be useful. Perhaps not, but I'm sorry America is not based solely on free trade, it's based on the interests of its citizens.
You wish. America is primarily interested in profits. Those who have profits, profit. Those who don't, suffer from those who profit from them. Those who stand in the way of making profits will be destroyed. Wake up, amd smell the American Way (TM).
No, they do not obviously believe, it could be a self-delusion, or just a plan to win the case.
You also have to take in consideration the fact Murdock (sp?) is an uber-conservative right winger. Some of the comments he made on the issue are quite depressing too.
The savings are in avoiding the bloated monopoly charges for long distance. Internet access is cheaper than international or long distance phone charges. That's why VoIP makes sooo much sense.
But that's still beta hype.