communications with Earth would be received within seconds rather than 10-20 minutes compared with Mars.
Could you please explain why this is relevant?
Finding out about something within seconds as opposed to 20 minutes seems inconsequential, when you consider that we can't actually react to it for days, weeks or months.
First of all, I would just plain love to have many gigs of memory, even if it's only accessible at today's speeds. To be able, for example, to actually search through my immense email archive at a reasonable speed, without needing to constantly fault to disk? Even if I have a whole movie loaded into memory and playing? Terrific.
Second of all, access speed will, of course, improve with time. It is almost a tautology - technology improves. Especially with associated technological leaps forward to drive the need for it, such as is the case with what's discussed in the article.
I don't know. Possibly. But I doubt it. You can get a computer that can adequately perform all the tasks that "Joe Sixpack" wants for what, like three hundred or four hundred dollars now. And in all likelyhood, prices will continue to drop.
And if the things you mention - "internet center", "media center" - are so important to your "Joe Sixpack", computers will come with them preconfigured and simple to use.
So ten years out, why would anyone want to buy an "internet center" and a "media center" and an "et cetera", when they can buy all of them (and more) at once, for a low low price of $29.95?
The Simpson Hit&Run is by far the best simpson game ever
No way. Simpsons' Road Rage was awesome. Simpsons' Hit and Run is boooooooooring. Except for the parts that are virtually identical to Simpsons' Road Rage.
Fine, fine, so just have multiple linked lists, one for each possible priority; an array of the count of timeslices you've given out to each priority; an array of the time you've given out to each priority. Loop through priorities (O(1)), decide the priority of the next process to give a timeslice to, and the amount of time that slice should be, using O(1) functions based on the time you've given to each priority and the number of slices you've given to each priority (O(1)), pop the head of the selected priority (O(1)), let it run (O(1)), push it back onto the tail of it's priority's queue (O(1)), rinse (O(1)), repeat (O(1)).
Again, as I have explained several times, I am not claiming that my scheme is so totally wonderful. I'm just saying that it's not difficult to satisfy the mere requirement "O(1) scheduler", so I don't see why so many posters are amazed by that mere fact. I'm sure that this latest version of mine is also not wonderful, but I'm not trying for a wonderful one, nor am I even claiming that if I did really try, mine would be even remotely as good as the real one described in the article. I'm just showing an O(1) scheduler, off the top of my head.
And to do that, all you need to do is make your decisions based on information that you've associated with priorities, rather than information that you've associated with processes. That is not a difficult concept; it's also not a "Eureka!" bolt out of the blue. Rather, it's probably the first idea that should occur to anybody when posed with the problem. And that's all I'm trying to convey. Maybe I should've just said that to begin with, instead of including a trivial example.
And how, exactly, does a subsystem say that it really wants attention NOW, under your scheme, and why, exactly, does that solution not work under my scheme?
Fine, remove that from my statement. I fail to see how deciding which process to switch to based upon its priority somehow qualifies as "scheduling" in a way that deciding how long a process will run when it is switched to will not.
it wasn't clear to me how any of the methods presented here or at Ars would prevent thread starvation from lower priority threads
I'm sure the real one resolves this problem, but my trivial example does, too, in a trivial way: Due to the round-robin nature of it, each process will be given a timeslice before any process is given two timeslices.
Yes, I am claiming that I have just designed, a few posts up, the most wonderful scheduler of all time. All other schedulers, including the one mentioned in the article, pale in comparison to the greatness of my scheduler. The world will be changed by my scheduler. Nations will fall, new ones will rise; the mighty shall be brought to their knees, and the righteous shall prevail, all thanks to my incredibly amazing scheduler.
Did you miss the part where I said "off the top of my head"? "Trivial example"? "I'm not saying that I just designed the world's greatest scheduler. Far from it, I'm sure"?
Did you miss the fact that the post you're replying to was a reply to a post that was essentially the same as your post? And that the post that you're replying to essentially said, "that's not what I'm saying"?
I fail to see why letting an individual process run for a constant length of time, but having a greater chance of switching to a higher priority process at any particular switch, somehow qualifies as "scheduling" in a way that having an equal chance of switching to each process at any particular switch, but letting the process run for a length of time dependent upon its priority, does not.
I'm not saying that I just designed the world's greatest scheduler. Far from it, I'm sure.
I'm just saying, I don't get the concept that merely making an O(1) scheduler is so incredibly difficult, and it's so utterly amazing that they were able to do so.
I don't understand why it's so difficult to make an O(1) scheduler.
Trivial example (I'm sure it can be improved upon, it's just off the top of my head to show that O(1) is not difficult to make):
There are a fixed number of possible priorities. Keep an array of that many integers. At a particular index, store the number of processes with that particular priority.
Keep a linked list of the processes. When a new process is created, put it on the end of the list. When an old process dies, remove it from the list.
When it comes time to decide what process to give a time slice to:
(1) Loop through the array of processes at particular priorities. For a priority P, apply some O(1) function to the number of processes at that priority (basically, a weighting function - the higher the priority, the higher the weight). Sum over all priorities. Since there are a constant number of priorities, and since your function f is O(1), this operation is also O(1).
(2) Pop the top process off of the list (this is also O(1), of course). Check the priority of the process. Apply some O(1) function g to the priority and to the number that you arrived at in step (1). The result of function g is an amount of time. Basically, you're getting something like a percentage of total time that should be applied to this particular process, based on its priority and those of all the other processes.
(3) Let the process execute for that amount of time.
(4) Put the process on the tail of the list (also O(1), of course).
(5) Goto step (1).
Sorry about the heretical use of goto. But anyway, there you have an O(1) scheduler. What's the big deal?
There is no reason someone wouldn't want a monitor.
How about "because I already have more than I need, because they take up space, because I have never had a monitor fail on me, and because if enough of my monitors did fail on me that I would need another, I would simply go out to the store and get another"?
When a person goes to the store to buy kleenex, they go to a certain aisle and see (from their technically incorrect point of view) a bunch of different competing brands of kleenex. One of them actually says "Kleenex", but that's not all that likely to register, or to make much of a difference even if it does register.
Assuming that the word "google" does become kleenexed, then when a person wants to "google" something, they will type "google" into their browser, and will wind up going to the REAL Google.
If, through some other method, they happened to stumble upon Alta Vista, they might consider it to be a "google", just like they consider ScotTissue to be "kleenex". But they really do see the ScotTissue "kleenex" right there next to the Kleenex "kleenex", and the same cannot be said of the Alta Vista "google" and the Google "google".
I would be very surprised if that chess program was written by only one person, so in truth the human is playing against a group, who have the combined knowledge of thier chess intelligence plus the whole history of chess they can reference.
I don't think that's entirely accurate.
I'm pretty confident that it would be significantly easier for me to write a chess program that is better than me at chess than it would be for me to become as good as that hypothetical program.
I just read one that actually resulted in the bad guy sending ten euros as a "show of faith".
How about, anybody who wants to try these reverse scams, explicitly go into it aiming for some small amount of money like this, but instead of having them Western Union the mone to a fake name, have them send the money via regular mail to that same fake name, but with the address of your favorite charity?
That's simply not true. The average person getting a call or e-mail asking for this info does not hand it over. One in a hundred, or one in a thousand, or one in some large number do.
If you walk up to a few hundred thousand people and ask for their account numbers and PINs, yes, you're going to get many punches in the mouth. But you might also get an account number and a PIN, because one of the people that you walk up to is a complete idiot.
It's not that the medium makes people stupider. It's that it's much, much easier to ask a hundred thousand people through email than it is to walk up to a hundred thousand people.
Slashdot Mirror
communications with Earth would be received within seconds rather than 10-20 minutes compared with Mars.
Could you please explain why this is relevant?
Finding out about something within seconds as opposed to 20 minutes seems inconsequential, when you consider that we can't actually react to it for days, weeks or months.
I guess I don't follow your reasoning.
First of all, I would just plain love to have many gigs of memory, even if it's only accessible at today's speeds. To be able, for example, to actually search through my immense email archive at a reasonable speed, without needing to constantly fault to disk? Even if I have a whole movie loaded into memory and playing? Terrific.
Second of all, access speed will, of course, improve with time. It is almost a tautology - technology improves. Especially with associated technological leaps forward to drive the need for it, such as is the case with what's discussed in the article.
I don't know. Possibly. But I doubt it. You can get a computer that can adequately perform all the tasks that "Joe Sixpack" wants for what, like three hundred or four hundred dollars now. And in all likelyhood, prices will continue to drop.
And if the things you mention - "internet center", "media center" - are so important to your "Joe Sixpack", computers will come with them preconfigured and simple to use.
So ten years out, why would anyone want to buy an "internet center" and a "media center" and an "et cetera", when they can buy all of them (and more) at once, for a low low price of $29.95?
Nasssssty little Indianses steals my IT jobseses! My precious, precious IT jobseses! Cheats, they is!
China is communist in name only. They're a capitalist dictatorship.
The Simpson Hit&Run is by far the best simpson game ever
No way. Simpsons' Road Rage was awesome. Simpsons' Hit and Run is boooooooooring. Except for the parts that are virtually identical to Simpsons' Road Rage.
Right, and then you're surfing a linked list.
No I'm not. I'm popping the head, and pushing onto the tail. Both of these are O(1) operations.
I am never traversing the list.
Fine, fine, so just have multiple linked lists, one for each possible priority; an array of the count of timeslices you've given out to each priority; an array of the time you've given out to each priority. Loop through priorities (O(1)), decide the priority of the next process to give a timeslice to, and the amount of time that slice should be, using O(1) functions based on the time you've given to each priority and the number of slices you've given to each priority (O(1)), pop the head of the selected priority (O(1)), let it run (O(1)), push it back onto the tail of it's priority's queue (O(1)), rinse (O(1)), repeat (O(1)).
Again, as I have explained several times, I am not claiming that my scheme is so totally wonderful. I'm just saying that it's not difficult to satisfy the mere requirement "O(1) scheduler", so I don't see why so many posters are amazed by that mere fact. I'm sure that this latest version of mine is also not wonderful, but I'm not trying for a wonderful one, nor am I even claiming that if I did really try, mine would be even remotely as good as the real one described in the article. I'm just showing an O(1) scheduler, off the top of my head.
And to do that, all you need to do is make your decisions based on information that you've associated with priorities, rather than information that you've associated with processes. That is not a difficult concept; it's also not a "Eureka!" bolt out of the blue. Rather, it's probably the first idea that should occur to anybody when posed with the problem. And that's all I'm trying to convey. Maybe I should've just said that to begin with, instead of including a trivial example.
And how, exactly, does a subsystem say that it really wants attention NOW, under your scheme, and why, exactly, does that solution not work under my scheme?
Nobody suggested constant size timeslices.
Fine, remove that from my statement. I fail to see how deciding which process to switch to based upon its priority somehow qualifies as "scheduling" in a way that deciding how long a process will run when it is switched to will not.
it wasn't clear to me how any of the methods presented here or at Ars would prevent thread starvation from lower priority threads
I'm sure the real one resolves this problem, but my trivial example does, too, in a trivial way: Due to the round-robin nature of it, each process will be given a timeslice before any process is given two timeslices.
Yes, I am claiming that I have just designed, a few posts up, the most wonderful scheduler of all time. All other schedulers, including the one mentioned in the article, pale in comparison to the greatness of my scheduler. The world will be changed by my scheduler. Nations will fall, new ones will rise; the mighty shall be brought to their knees, and the righteous shall prevail, all thanks to my incredibly amazing scheduler.
Did you miss the part where I said "off the top of my head"? "Trivial example"? "I'm not saying that I just designed the world's greatest scheduler. Far from it, I'm sure"?
Did you miss the fact that the post you're replying to was a reply to a post that was essentially the same as your post? And that the post that you're replying to essentially said, "that's not what I'm saying"?
I fail to see why letting an individual process run for a constant length of time, but having a greater chance of switching to a higher priority process at any particular switch, somehow qualifies as "scheduling" in a way that having an equal chance of switching to each process at any particular switch, but letting the process run for a length of time dependent upon its priority, does not.
No. I am looping through, and operating upon, a table of priorities, not a table of processes.
There are a constant number of priorities. Hence, the step in question is O(1).
I'm not saying that I just designed the world's greatest scheduler. Far from it, I'm sure.
I'm just saying, I don't get the concept that merely making an O(1) scheduler is so incredibly difficult, and it's so utterly amazing that they were able to do so.
I don't understand why it's so difficult to make an O(1) scheduler.
Trivial example (I'm sure it can be improved upon, it's just off the top of my head to show that O(1) is not difficult to make):
There are a fixed number of possible priorities. Keep an array of that many integers. At a particular index, store the number of processes with that particular priority.
Keep a linked list of the processes. When a new process is created, put it on the end of the list. When an old process dies, remove it from the list.
When it comes time to decide what process to give a time slice to:
(1) Loop through the array of processes at particular priorities. For a priority P, apply some O(1) function to the number of processes at that priority (basically, a weighting function - the higher the priority, the higher the weight). Sum over all priorities. Since there are a constant number of priorities, and since your function f is O(1), this operation is also O(1).
(2) Pop the top process off of the list (this is also O(1), of course). Check the priority of the process. Apply some O(1) function g to the priority and to the number that you arrived at in step (1). The result of function g is an amount of time. Basically, you're getting something like a percentage of total time that should be applied to this particular process, based on its priority and those of all the other processes.
(3) Let the process execute for that amount of time.
(4) Put the process on the tail of the list (also O(1), of course).
(5) Goto step (1).
Sorry about the heretical use of goto. But anyway, there you have an O(1) scheduler. What's the big deal?
There is no reason someone wouldn't want a monitor.
How about "because I already have more than I need, because they take up space, because I have never had a monitor fail on me, and because if enough of my monitors did fail on me that I would need another, I would simply go out to the store and get another"?
Really! How interesting. It sounds a little familiar, though... I'm trying to think of where I recently read that information...
Oh yeah, the article.
Half an hour, driving.
How does it lose mass?
Over half a trillion years from now.
Their old offices were extraordinarily crowded but had lots of character (buildings 0, pi and e)
As a practical joke, they could tell the new guys that there's a meeting in the main conference room in building i.
There's a difference here, though:
When a person goes to the store to buy kleenex, they go to a certain aisle and see (from their technically incorrect point of view) a bunch of different competing brands of kleenex. One of them actually says "Kleenex", but that's not all that likely to register, or to make much of a difference even if it does register.
Assuming that the word "google" does become kleenexed, then when a person wants to "google" something, they will type "google" into their browser, and will wind up going to the REAL Google.
If, through some other method, they happened to stumble upon Alta Vista, they might consider it to be a "google", just like they consider ScotTissue to be "kleenex". But they really do see the ScotTissue "kleenex" right there next to the Kleenex "kleenex", and the same cannot be said of the Alta Vista "google" and the Google "google".
I would be very surprised if that chess program was written by only one person, so in truth the human is playing against a group, who have the combined knowledge of thier chess intelligence plus the whole history of chess they can reference.
I don't think that's entirely accurate.
I'm pretty confident that it would be significantly easier for me to write a chess program that is better than me at chess than it would be for me to become as good as that hypothetical program.
I just read one that actually resulted in the bad guy sending ten euros as a "show of faith".
How about, anybody who wants to try these reverse scams, explicitly go into it aiming for some small amount of money like this, but instead of having them Western Union the mone to a fake name, have them send the money via regular mail to that same fake name, but with the address of your favorite charity?
That's simply not true. The average person getting a call or e-mail asking for this info does not hand it over. One in a hundred, or one in a thousand, or one in some large number do.
If you walk up to a few hundred thousand people and ask for their account numbers and PINs, yes, you're going to get many punches in the mouth. But you might also get an account number and a PIN, because one of the people that you walk up to is a complete idiot.
It's not that the medium makes people stupider. It's that it's much, much easier to ask a hundred thousand people through email than it is to walk up to a hundred thousand people.