Why? Virtual memory is your disk caching. If you have your preferences set to refetch cached pages each time your run Netscape (like most people do), then it seems to me that disk caching just wastes hard drive space between browsing sessions.
Set your memory cache to 40M and marvel at the wonders of modern operating systems...
Uh, doesn't adding memory totals from top give an inaccurate picture of real memory usage because it counts shared pages multiple times?
E.g., if I fork() (which is pretty much the same as making a new thread in the Linux world), all the text pages that are shared will be listed under the memory total for both the parent and child process in top. If I sum the memory usages, then, I'm counting the shared pages twice.
Which can give an unfair appraisal of the memory hunger of a multithreaded program.
Well, to be fair, QNX has a microkernel-based architecture, so the core services provided by the kernel are minimal. The chances of bugs are thereby greatly diminished compared to an OS with a ridiculously monolithic kernel like, say, Linux.
Ug!!! Did you folks read the original question? "Drop dead reliability" was requested.
If any of you claims to be able to offer "drop dead reliability" in a DIY mail setup, you're lying. What happens when your power goes out? UPS? What happens when your power goes out for a day and a half? What happens when your hard drive crashes and you lose every email you've received in the last year? What happens when your house burns down?
Highly reliable data centers, like those that handle email for large national ISPs, often cost millions of dollars, are redundantly connected to multiple backbone providers, are protected against fire, are redundantly connected to multiple independent power grids, etc.
I would never choose my home computer to be the single point of failure/destruction for all my email. Give me MSN Hotmail over that any day.
"So they really only lose the cost of the paper and toner to print the stock, and they gain the money from the employees who exercise the options."
If I have a key lime pie I really want to eat and I decide to divide it between me and 5000 other people instead of just me and 5 other people, I've lost more than just the work that went into cutting the pie. I've lost key lime pie.
...that means that you have to flush the CPU cache for each new connection (rotating the memory space).
Depending on your architecture's cache design, this isn't always true. Virtual caches that include PIDs in cache tags obviously don't have to be flushed; all that's needed is a change to the cache's PID register. The same applies to TLBs. The Linux Cache Flush Architecture.
Additionally, unless you put in enough memory, you're going to have to swap to disk throughout the rotation.
This is why web servers have lots of memory. But, that aside, in Linux text pages are shared; you don't have 700 copies of your program's code in memory. Clearly stacks and data pages aren't sharable, but your MT system also needs separate memory for each thread's stack and thread-local data. If I had large amounts of data that was usefully shared by my threads, I would shmem that same data in a process-based system.
But the most telling observation is how similar processes are to threads from the Linux kernel's perspective (which you could use to dog on Linux's threading support, but I wouldn't). Both are created by the kernel's clone call, which takes flags that indicate which process stuff (FDs, data, etc.) should be duplicated and which should be shared by the cloned process/thread. If you ever wondered why threads have their own PIDs in Linux...
Threads aren't god's gift to programmers. But they're still nice:)
Well, I work for a non-profit broadcast radio station, and, like many other radio stations, we have a small webcast of our FM broadcast. We have been asked to pay separate fees for the webcast, in addition to our regular ASCAP/BMI/SESAC fees. This seems unreasonable to me.
I assume there is a regular ASCAP/BMI mechanism for collecting and dsitributing these royalties
ASCAP/BMI/SESAC distribute royalties to participating artists based on the percentage of airtime they get. Playlists are surveyed to come up with a probability density function.
I don't see why this doesn't work for webcasting: if you factor in the number of listeners, it's somewhat reasonable.
MBONE is not synonymous with multicast. MBONE started way-back-when as a hack to make interdomain multicast work over a largely unicast Internet. In the future (and the present, if you consider the well-designed, natively multicast-capable homogenous internet that is Internet2) there will be better native support for interdomain multicast routing.
For a good survey of the the past, present, and future of interdomain multicast routing, try this paper.
As others have mentioned, yes, flow control is a problem, and, yes, reliability is a problem. There are many solutions to both problems that have been researched (largely in academia), but flow control can't really be solved if you're trying to distribute RedHat over multicast to half a million people who are on disparate links.
Someone a few posts up mentioned the Digital Fountain idea, but neglected to provide a link. Digital Fountain aims to solve the problems that are being discussed here for exactly the kinds of applications that are being discussed here. The paradigm is that random bytes are constantly flowing from the fountain (the multicaster) and the recipients fill up their buckets with the random bytes until a file is formed. Read their papers for a more mathematically rigorous explanation...
Slashdot Mirror
Why? Virtual memory is your disk caching. If you have your preferences set to refetch cached pages each time your run Netscape (like most people do), then it seems to me that disk caching just wastes hard drive space between browsing sessions.
Set your memory cache to 40M and marvel at the wonders of modern operating systems...
Uh, doesn't adding memory totals from top give an inaccurate picture of real memory usage because it counts shared pages multiple times?
E.g., if I fork() (which is pretty much the same as making a new thread in the Linux world), all the text pages that are shared will be listed under the memory total for both the parent and child process in top. If I sum the memory usages, then, I'm counting the shared pages twice.
Which can give an unfair appraisal of the memory hunger of a multithreaded program.
Do we even want to talk about how much Linux Netscape and Enlightenment crash?
Windows is eons more stable for desktop work and web browsing than Linux.
Nobody's attacking DOS. They're attacking DOSattackers. So they're defending DOS.
Don't do drugs. Drugs aren't cool.
Stay in school.
Nobody ever says "I want to be a DoS attacker when I grow up."
Well, to be fair, QNX has a microkernel-based architecture, so the core services provided by the kernel are minimal. The chances of bugs are thereby greatly diminished compared to an OS with a ridiculously monolithic kernel like, say, Linux.
The ISP may be down, the IMAP server map be down, but I doubt mail is getting lost. How many yahoo mail messages have you lost, Ralph?
If any of you claims to be able to offer "drop dead reliability" in a DIY mail setup, you're lying. What happens when your power goes out? UPS? What happens when your power goes out for a day and a half? What happens when your hard drive crashes and you lose every email you've received in the last year? What happens when your house burns down?
Highly reliable data centers, like those that handle email for large national ISPs, often cost millions of dollars, are redundantly connected to multiple backbone providers, are protected against fire, are redundantly connected to multiple independent power grids, etc.
I would never choose my home computer to be the single point of failure/destruction for all my email. Give me MSN Hotmail over that any day.
If I have a key lime pie I really want to eat and I decide to divide it between me and 5000 other people instead of just me and 5 other people, I've lost more than just the work that went into cutting the pie. I've lost key lime pie.
google
Depending on your architecture's cache design, this isn't always true. Virtual caches that include PIDs in cache tags obviously don't have to be flushed; all that's needed is a change to the cache's PID register. The same applies to TLBs. The Linux Cache Flush Architecture.
Additionally, unless you put in enough memory, you're going to have to swap to disk throughout the rotation.
This is why web servers have lots of memory. But, that aside, in Linux text pages are shared; you don't have 700 copies of your program's code in memory. Clearly stacks and data pages aren't sharable, but your MT system also needs separate memory for each thread's stack and thread-local data. If I had large amounts of data that was usefully shared by my threads, I would shmem that same data in a process-based system.
But the most telling observation is how similar processes are to threads from the Linux kernel's perspective (which you could use to dog on Linux's threading support, but I wouldn't). Both are created by the kernel's clone call, which takes flags that indicate which process stuff (FDs, data, etc.) should be duplicated and which should be shared by the cloned process/thread. If you ever wondered why threads have their own PIDs in Linux...
Threads aren't god's gift to programmers. But they're still nice :)
Well, I work for a non-profit broadcast radio station, and, like many other radio stations, we have a small webcast of our FM broadcast. We have been asked to pay separate fees for the webcast, in addition to our regular ASCAP/BMI/SESAC fees. This seems unreasonable to me.
ASCAP/BMI/SESAC distribute royalties to participating artists based on the percentage of airtime they get. Playlists are surveyed to come up with a probability density function.
I don't see why this doesn't work for webcasting: if you factor in the number of listeners, it's somewhat reasonable.
For a good survey of the the past, present, and future of interdomain multicast routing, try this paper.
As others have mentioned, yes, flow control is a problem, and, yes, reliability is a problem. There are many solutions to both problems that have been researched (largely in academia), but flow control can't really be solved if you're trying to distribute RedHat over multicast to half a million people who are on disparate links. Someone a few posts up mentioned the Digital Fountain idea, but neglected to provide a link. Digital Fountain aims to solve the problems that are being discussed here for exactly the kinds of applications that are being discussed here. The paradigm is that random bytes are constantly flowing from the fountain (the multicaster) and the recipients fill up their buckets with the random bytes until a file is formed. Read their papers for a more mathematically rigorous explanation...