Personally, I'd kill to have this, assuming it also covers international calling.
It's extra.
My gf and I are spending nearly $80/month on calls back and forth from.sg.
Yeah, I don't think you're going to be able to do much better than.069 or.068 per minute. (I assume you guys are talking over 30 minutes a day.) If you both have computers with decent Internet connections, though, why don't you do the VoIP yourself?
I'm sure this is a troll, but I'm going to respond anyway.
If we ever really want to see Linux on the desktop, we need to resolve exactly these issues and a few others
Data integrity matters very very very little to desktop users. It matters on corporate servers, but not on my desktop. If data integrity is an integral part of success in the desktop market, then why do OSes with FAT(32) dominate the market?
And with regard to Linux file systems, I think XFS is a good cool punk rock solid journaling FS. Though their website seems to be down now.
A 494-word rant for a first post? Do you think he thought that up and started writing it after the story was posted? And was so adroit and speedy that he finished writing in 20 seconds?
The reason the troll is offtopic is because it was written before the topic existed.
Software pitch correctors (at least, the Antares Auto-Tune 3 plugin I use) let you manually set pitch correction for different notes to achieve this intentional inaccuracy.
Further, Auto-Tune is midi controllable, so (though I don't have it in front of me right now to check) I'd imagine it responds to midi pitch bend controller information.
You might check out XWT. It's a lightweight windowing toolkit for web-based applications. He's got some cool demos. (Though the mail demo crashed my Mozilla when I tried to exit...)
Also, as a former employee, I feel compelled to point GoToMyPC, which is like VNC, but with better compression, nicities like remote printing, and most importantly firewall penetration. (But, yeah, Windows only and expensive.)
What are you talking about? Even the slightest Star Wars fan knows that the Emperor's name was Palpatine. Are you saying that they are different people!?
Check out the Palpatine bio on starwars.com. The relevant quote is: "In the Death Star, high above the Battle of Endor, Luke refused the Emperor's newfound dark side power, and so Palpatine used his deadly Force lightning to attack the young Jedi."
Next are you going to suggest that the Anakin Skywalker from Phantom Menace isn't the same Anakin Skywalker who became Darth Vader?!
Jar Jar is a mockery of these values. He's unintelligent, a coward, and lazy. He's mechanically inept. His clumsiness makes him such a burden on his society that they force him into exile. He is careless with military weaponry. He almost breaks the pod-racer by dropping an tool into a jet engine! And in spite of all of this, he succeeds too!
Jar Jar is the new (well, old) C3PO. Reread your description and tell me this isn't the bumbling, slightly annoying role that Lucas was trying to recreate.
...the user-friendly distro that tried to duplicate the familiar WindowsXP UI feel under Linux...
Well, I don't have Lycoris in front of me to feel with my own two hands, but from the screenshots it's "feeling" a lot like KDE with a cloud wallpaper.
Sorry, but despite the article it appears terrorism is once again eliminating freedoms internally.
What is this "despite the article" business? "Despite what the facts are, I'm going to pretend something of my own design and write a post about it..."
Their Chief Scientist said:
"...support for the Freedom network offering was removed from the client code base well before the recent tragedies of September 11..."
But they've also found that anything that hits the disk, or hits other slow services (e.g. back-end databases, transaction processing) works better in a multithreaded mode.
I don't think you're understanding it.
Things that hit slow services (like databases) do not run better in a multithreaded server; they run better in an event-driven server, the same as for a cached workload. Why on earth would MP/MT be better just because the tasks were slow?
The reason that highly disk-bound workloads do well in a multiprocessed or multithreaded (kernel threads, not user threads) server is actually because very few operating systems provide non-blocking IO for disks. Nonblocking disk IO is more challenging for a kernel to implement, since you have to keep track of buffers and states outside the kernel call stack. For network IO, the buffers are all already there in the kernel, so NBIO is relatively trivial: just let the application know when data has arrived. Therefore, you can't write a pure event-driven server that does lots of disk IO under most OSes, because your server will block (which violates the prime directive of event-driven programming). That is why Flash spawns helper processes to handle disk IO.
If you're working with "back-end databases or transaction processing" (which occurs over the network), then NBIO is no problem, and you should write a pure event-driven server. If you're writing a server that involves the disk, then you should use a hybrid scheme like what is proposed in SEDA.
The main point that we get from these papers (particularly the more recent SEDA), though, is that, if you have to use threads, your hybrid design should use a thread pool of a fairly small number of threads, and you should use events and event queues for the rest. The poster I was replying to said that "three to four hundred threads could be running at any given moment inside the server." I don't need to know anything about the particulars of his application to know that he's going to lose with his "large-scale" implementation: look at figure 2 in the SEDA paper from SOSP. Notice how the throughput starts to seriously degrade when you get past 8 threads?! And how, by the time you get to 128 threads, the throughput is as bad as when you have 1 thread! What does the graph say when we reach the 300-400 threads that our subject's server had? Notice how the throughput has dropped to well below half the single-thread throughput, and the latency is a factor of five greater than the linear latency? This ungraceful service degradation under load is inherent to thready servers, and is largely independent of whether your threads are blocking for the disk or twiddling their thumbs--there is no reason to ever have this many threads. The only point of multiple kernel threads in disk-bound workloads is to give the disk enough work to do to make its read batching and arm scheduling efficient. For this purpose, you don't get any additional returns for having more than about a dozen outstanding reads at any time. Notice how SEDA's webserver caps the number threads in the thread pool of each of its three stages at 20, and the thread pool controller keeps the optimal size far below this on average.
Please read your own citations and call out the domain of applicability of such comments.
Please understand the content of the citations before presuming to school me on them.
So please don't slam someone for having used an approach that is superior in many domains
So, in conclusion, having 400 threads in your server isn't superior in any domain. And I wasn't "slamming" him at all: 1) most servers in the world are multithreaded, so I hardly have reason to be particularly critical of him, and 2) Java didn't even have NBIO when he wrote the server a year ago, so the event-driven design wasn't an option anyway (although you should probably have a much lower cap on the size of your thread pool; Apache won't spawn endless processes until it kills your machine).
Slashdot Mirror
Hey, dude, my parent brought it up before me!
(The relevant part of the page is under "News & Updates" on the left.)
No ads for OSDI, SIGMOD, and SIGCOMM, though.
Clicks / Day: 210.0
Average Cost-Per-Click: $0.06
Cost / Day: $11.31
Average Position: 1.3
Try it yourself (click on "no obligation to buy").
And with regard to Linux file systems, I think XFS is a good cool punk rock solid journaling FS. Though their website seems to be down now.
The reason the troll is offtopic is because it was written before the topic existed.
Software pitch correctors (at least, the Antares Auto-Tune 3 plugin I use) let you manually set pitch correction for different notes to achieve this intentional inaccuracy.
Further, Auto-Tune is midi controllable, so (though I don't have it in front of me right now to check) I'd imagine it responds to midi pitch bend controller information.
Also, as a former employee, I feel compelled to point GoToMyPC, which is like VNC, but with better compression, nicities like remote printing, and most importantly firewall penetration. (But, yeah, Windows only and expensive.)
Check out the Palpatine bio on starwars.com. The relevant quote is: "In the Death Star, high above the Battle of Endor, Luke refused the Emperor's newfound dark side power, and so Palpatine used his deadly Force lightning to attack the young Jedi."
Next are you going to suggest that the Anakin Skywalker from Phantom Menace isn't the same Anakin Skywalker who became Darth Vader?!
Little "analog" sensor-actuator robots... a little too reminiscent of the homework I should be working on...
Am I the only person who was instantly reminded of menstrual cycle synchronization?
Had you heard of it??????????????
Their Chief Scientist said: "...support for the Freedom network offering was removed from the client code base well before the recent tragedies of September 11..."
Only when they argue with me.
The reason that highly disk-bound workloads do well in a multiprocessed or multithreaded (kernel threads, not user threads) server is actually because very few operating systems provide non-blocking IO for disks. Nonblocking disk IO is more challenging for a kernel to implement, since you have to keep track of buffers and states outside the kernel call stack. For network IO, the buffers are all already there in the kernel, so NBIO is relatively trivial: just let the application know when data has arrived. Therefore, you can't write a pure event-driven server that does lots of disk IO under most OSes, because your server will block (which violates the prime directive of event-driven programming). That is why Flash spawns helper processes to handle disk IO.
If you're working with "back-end databases or transaction processing" (which occurs over the network), then NBIO is no problem, and you should write a pure event-driven server. If you're writing a server that involves the disk, then you should use a hybrid scheme like what is proposed in SEDA.
The main point that we get from these papers (particularly the more recent SEDA), though, is that, if you have to use threads, your hybrid design should use a thread pool of a fairly small number of threads, and you should use events and event queues for the rest. The poster I was replying to said that "three to four hundred threads could be running at any given moment inside the server." I don't need to know anything about the particulars of his application to know that he's going to lose with his "large-scale" implementation: look at figure 2 in the SEDA paper from SOSP. Notice how the throughput starts to seriously degrade when you get past 8 threads?! And how, by the time you get to 128 threads, the throughput is as bad as when you have 1 thread! What does the graph say when we reach the 300-400 threads that our subject's server had? Notice how the throughput has dropped to well below half the single-thread throughput, and the latency is a factor of five greater than the linear latency? This ungraceful service degradation under load is inherent to thready servers, and is largely independent of whether your threads are blocking for the disk or twiddling their thumbs--there is no reason to ever have this many threads. The only point of multiple kernel threads in disk-bound workloads is to give the disk enough work to do to make its read batching and arm scheduling efficient. For this purpose, you don't get any additional returns for having more than about a dozen outstanding reads at any time. Notice how SEDA's webserver caps the number threads in the thread pool of each of its three stages at 20, and the thread pool controller keeps the optimal size far below this on average.
Please understand the content of the citations before presuming to school me on them. So, in conclusion, having 400 threads in your server isn't superior in any domain. And I wasn't "slamming" him at all: 1) most servers in the world are multithreaded, so I hardly have reason to be particularly critical of him, and 2) Java didn't even have NBIO when he wrote the server a year ago, so the event-driven design wasn't an option anyway (although you should probably have a much lower cap on the size of your thread pool; Apache won't spawn endless processes until it kills your machine).