The OS is based on the On-Time RT-Kernel32 scheduler. Most of the other stuff is written by me (like drivers/fs/tcpip etc).
Although you can configure On-Time's scheduler in many ways, we use it as a priority based, preemtive scheduler. This means that the highest priority task always runs if it wants to. When there are multiple tasks of the same priority that want to run, they are scheduled using round robin. This is largely based on the timer interrupt (which we run at 1000 Hz) which means that they preempt one an other based on time. Essentially the task that has run for the least amount of time runs.
So a task switch occurs either 'implied' by the task blocking on a semaphore/lock or 'preemptive' by the scheduler. The scheduler is called after processing each hardware interrupt (such as the timer) to assure the right task runs.
As you can see from On-Time's website, context switching is fast, even if we switched every timer interrupt, on our PIII-500 we would spend about 200 microseconds per second on the context switching.
Under the hood, it's an entire different approach than Linux and I get confused sometimes about the way things work in Linux. That and I don't really stay up-to-date. I'm happy to see Roberts work, because it addressed the main concern I've had with Linux in the past.
I think you misunderstand my point entirely. What I was trying to show is how the place of locks effect 'preemtiveness'. (And this is exactly what Robert is doing, by using the lower locks that now exist for SMP kernels).
It's all fine and dandy to schedule a high-prio task, but if your kernel is locked by a lo-prio task, it's useless. In other words, in order to make a kernel preemptive, you need to move locks down to the lowest possible place.
For example, the Linux IDE driver is locked by the kernel for the duration of an entire request, no matter how big. Only one request is handed to the driver at a time. So if an app issues a very large read request and finally gets a hold of the lock, the IDE driver can not be preempted to handle an other request until the entire request is fullfilled. Sure, it will call schedule so other tasks can run, as long as they don't require the IDE driver. If they do, they have to wait until the entire read request is done. The point is that by putting the lock lower, you make it possible for other tasks to obtain the lock, allowing preempting.
a preemptive kernel will not preempt a task for a task with the same priority
Maybe Roberts patches don't, but I know my OS does.
Chizen said in the article that it can cost up to $750,000 to produce a Chinese-language version of a product, and extensive piracy makes it difficult for Adobe to recoup those costs.
Duh, the way Adobe charges for their product that's only, what, 1,000 boxes?
The reason you have preemtive kernels is so that priority tasks are not affected by lower prioriy tasks. Not the reason you gave above.
Really? So what about tasks that are of equal priority?
I maybe should have explicitly said so, but I assumed the threads (apps) run at the same priority. This way it was a bit easier to explain without going into details regarding scheduling.
Preemtive kernels also improve responsiveness between equal priority tasks.
Yet a lot of people actually seem to buy this whining about the death of the recording industry
Yeah, it's interesting to see how much sympathy these guys get when you consider their attitude towards accepting new technologies.
From the very beginning, they have been aggressively defending their product, instead of a more positive, active involvement in the Internet as it emerged. I believe there have been many opportunities for the recording industry that they let go to waste. Why should we have mercy for these folks.
I'm very disappointed. Many years ago when I still lived in Holland I talked to some people I knew in the industry (Polydor). I could see all these opportunities the Internet would bring, and I was pleased to hear they where actually quite on top of what was happening with the Internet. Unfortunately nothing good came out of that.
They have been hindering progress, and it almost sounds like they've just begun. The fact that I can order a CD on Amazon, even listen to samples, but CAN'T download the entire album is just ludicrous. But not being able to get the music on to my MP3 walkman because the CD is copy protected is plain insane.
Donating to the EFF and writing your congressmen is more important than ever.
For those that don't really understand the importance of preemptive multitasking (and from reading some comments, there are a few of you out there:-O), let's explain this through an example.
Consider application (a) that wants to read 128MB of data from the disk and application (b) that wants to read 1KB of data.
Let's say that the disk transfers @ 1MB/sec and let's assume application (a) issues the read 1 second before application (b) is started.
The sequence of calls for each app will look something like this:
1) program calls read
2) read is handled by the top level file system and is handed down to the proper file system
3) the file system calls the block device
4) the block device driver breaks up the request into the maximum block size the device can handle per request (for example 256 sectors for IDE)
5) for every request, the block device sends request to physical drive
6) drive transfers data to host
7) drive indicates 'done'
8) goto 5 until done
9) file system returns
10) read returns
It's important to know that there may be limitations on the number of requests any stage can handle simultaneously. For example, an IDE drive can only handle one request at a time. Some Operating Systems however introduce even tighter restrictions, because for example the block device driver was written, assuming only one request at a time would be allowed.
Take for example an OS where the kernel assures that no more that one request is pending between step 3) and 9).
This would have the following effect on our apps: app (a) is allowed to call step 4) because it is the first request. One second later, app (b) arrives at step 3) and is blocked. It is not allowed to enter step 4) until app (a) is done and passes step 9). Effectively this means that app (b) has to wait for 127 seconds before it gets access to step 4).
Now consider an OS where the file system and drivers can handle multiple requests. It still has to assure that the physical drive receives only one request though, so it permits only access of one app between step 5) and 7). App (a) arrives at step 5) first, so it gets to start sending requests to the drive. One second later, app (b) arrives at step 5) and has to wait for app (a) to finish it's current request to the drive. As soon as this request is done though, app (a) gets to step 8). Now we have both app (a) and app (b) wanting to have access to step 5). Depending on the scheduler either one will be granted access. There's a good change that app (b) will get access, and thus it only had to wait the time it took for app (a) to finish it's outstanding request, which takes max 1/8th of a second (256 sectors = 128KB) in this example.
Btw. you may notice though that there's more likely to be an (expensive) seek introduced by allowing app (b) to interrupt the transfer of app (a)
You can see how moving the 'lock' deeper in to the OS improves responsiveness. I'm not going to start a flame war about which OS is better, all I will say is that MY OS locks steps 5) through 7):-)
No matter what, you can be sure that contrary to M$, these holes will be worked on 24/7 and fixed like yesterday.:)
I would have modded you down, but since you managed to squeeze in some nice and juicy, uncalled-for Microsoft bashing, I started doubting. And then I read:
Anyway, enjoy you uninformed, senseless bashing and flaming... trolls.
Wow, that did it, you didn't deserve to be modded down. That's a great troll! Thanks!
Re:The first Slashdot troll post investigation
on
KaZaa Suspends Downloads
·
· Score: -1, Offtopic
Digging deep into the history of slashdot, I found this poll [slashdot.org], which clearly indicates the vast majority does NOT want the moderation we have here today.
Been contradicting yourself much lately? Interesting use of 'deep into the history' and 'today' in one sentense.
I'll sacrifice my precious Karma to point that out.:o)
Before we know it, he's a moderator. I can't believe how cheap people are these days. Getting Microsoft all riled up for a little Karma on/.? Sjeesh...
And like the guy says, if you can hijack the string (= argv[1]) you can execute almost any program as root.
Since popen hands this to a shell, things like.. are expanded. E.g. you can execute most anything,- consider for example argv[1] = "../../usr/sbin/bla > "
This would basically execute
/usr/sbin/bla >/setup
If you want you can also remove the/setup by just adding "../usr/../usr/../usr" (or plain whitespace may work too) until you overflow the buffer and have snprintf throw the rest away.
In this case I don't know where argv[1] comes from, but it would have to be a very trustworthy source. In general it's fairly stupid to execute commands based on a parameter, especially as root.
I'm from the Netherlands, but in the US right now. The problem arose when I read the Palo Alto Daily about a week ago, where a professor was trying to explain how to use the 's.
Ever since, I've been horribly confused.:o)) I was never very good at foreign languages. In fact, not at my native language either.
Anyways, I read up on it, after my blunder here on/. so hopefully I have it down now.;)
a) You give up your basic rights provided to you by the law.
b) Because this can't legally be done under the US law, you agree that we will put the law aside and have Borland make the rules.
I mean, are these guys still in kindergarten?? This is obviously an agreement that will not hold up in court. However, it should actually be illegal to even ask someone to agree with it. In a way Borland is asking us to agree to break the law.
It's sad to see that a company like Borland even TRIES something like that. Even if they fix their rediculous agreement, they owe the public a huge appology for taking us for such morons.
I actually thought Timmys comment I don't think it's quite as cool-looking as the Stereolink 1200 demonstrated quite well that we are not talking Golden Ears here.
It's amazing how many people buy their audio equipment based on looks. It somehow doesn't occur to them that the audio quality should be at least part of the consideration.
I remember trying to convince my mom to buy a certain stereo because it sounded good (for the money). She replied: yeah, but THAT one LOOKS better. The fact that the sound it produced was horrible didn't weigh in very much.:-)
Which actually gives us a hint on where to start with decoding: there's an obvious pattern, however, the length chosen for the lines is not identical to the pattern.
In other words, first thing to do is rearranging the line lenghts to match the pattern.
00001000000001100000000000000000000000000*
00000000000001100000000000000000000000000*
00000000000001100000000000011001100100010*
00001100000000100000000000011000100000000*
(*end of line cut due to lameness filter)
The noise is obvious from the fourth line. It becomes a bit trick if you get noise in the time-domain, but still nothing to complex. It certainly looks like they use a fixed 'word' length.
And exactly how much would you want to pay for one?
It's easy enough for me to go over and put a bid on a couple. I could practically walk there.
If there are people that are seriously interested, let me know. I suspect there will be more bidders on these boxen though. I don't care to make money on them, and I don't mind paying for them in advance, I just need to get an idea of what people would want to realistically pay for them.
I wonder if the auction itself is going to be as/.ed as the site.
Unfortunately, most of the stuff is just nothing-fancy standard office equipment. Be wasn't living the hi-life like the dotcoms. It's too bad they didn't make it.
I don't think Stanford actually filed a lawsuit, but they where pretty close.
Re:The most offensive Slashdot article _ever_
on
Can China Pull An India?
·
· Score: 4, Interesting
Yeah, that statement annoyed me a lot too.
The poster seems to assume that all India and China has to offer in terms of software development is programming houses that provide services to US companies.
Although it's almost impossible to avoid any racist issues when discussing this matter, I do believe the use of these houses is a Good Thing.
First of all, it provides a way to distribute money from the US to countries that have a lower standard of living. Secondly, it promotes education. The combination of the two has proven to be very succesful in increasing the standard of living in places that need it.
In fact, much of the great free software we all use has non-US origins.
In fact, some of the not so great, not so free software was made in the US.:o)
Could you or anyone else that has good experience with these type of companies provide some details of those companies (website).
We have never outsourced our coding but we are certainly interested. There is some fear to overcome with management though. We have never had our source go outside the building for example (yep, closed source, for good reasons, believe me) so sending it overseas is not something that they'll do easily. And in our case we probably would have to do that.
It's basically a trust issue, so one of the best ways to start off is with a company that comes highly recommended. (Instead of replying to spam;o))
Slashdot Mirror
The OS is based on the On-Time RT-Kernel32 scheduler. Most of the other stuff is written by me (like drivers/fs/tcpip etc).
Although you can configure On-Time's scheduler in many ways, we use it as a priority based, preemtive scheduler. This means that the highest priority task always runs if it wants to. When there are multiple tasks of the same priority that want to run, they are scheduled using round robin. This is largely based on the timer interrupt (which we run at 1000 Hz) which means that they preempt one an other based on time. Essentially the task that has run for the least amount of time runs.
So a task switch occurs either 'implied' by the task blocking on a semaphore/lock or 'preemptive' by the scheduler. The scheduler is called after processing each hardware interrupt (such as the timer) to assure the right task runs.
As you can see from On-Time's website, context switching is fast, even if we switched every timer interrupt, on our PIII-500 we would spend about 200 microseconds per second on the context switching.
Under the hood, it's an entire different approach than Linux and I get confused sometimes about the way things work in Linux. That and I don't really stay up-to-date. I'm happy to see Roberts work, because it addressed the main concern I've had with Linux in the past.
Anyways, I hope this makes sense...
Yep, major fuck up: the current Linux IDE driver doesn't get locked for entire requests... Bad example, sorry.
The point still stands though for basically any resource that has a long (time-wise) lock on it.
I think you misunderstand my point entirely. What I was trying to show is how the place of locks effect 'preemtiveness'. (And this is exactly what Robert is doing, by using the lower locks that now exist for SMP kernels).
It's all fine and dandy to schedule a high-prio task, but if your kernel is locked by a lo-prio task, it's useless. In other words, in order to make a kernel preemptive, you need to move locks down to the lowest possible place.
For example, the Linux IDE driver is locked by the kernel for the duration of an entire request, no matter how big. Only one request is handed to the driver at a time. So if an app issues a very large read request and finally gets a hold of the lock, the IDE driver can not be preempted to handle an other request until the entire request is fullfilled. Sure, it will call schedule so other tasks can run, as long as they don't require the IDE driver. If they do, they have to wait until the entire read request is done. The point is that by putting the lock lower, you make it possible for other tasks to obtain the lock, allowing preempting.
a preemptive kernel will not preempt a task for a task with the same priority
Maybe Roberts patches don't, but I know my OS does.
Chizen said in the article that it can cost up to $750,000 to produce a Chinese-language version of a product, and extensive piracy makes it difficult for Adobe to recoup those costs.
Duh, the way Adobe charges for their product that's only, what, 1,000 boxes?
The reason you have preemtive kernels is so that priority tasks are not affected by lower prioriy tasks. Not the reason you gave above.
Really? So what about tasks that are of equal priority?
I maybe should have explicitly said so, but I assumed the threads (apps) run at the same priority. This way it was a bit easier to explain without going into details regarding scheduling.
Preemtive kernels also improve responsiveness between equal priority tasks.
Yet a lot of people actually seem to buy this whining about the death of the recording industry
Yeah, it's interesting to see how much sympathy these guys get when you consider their attitude towards accepting new technologies.
From the very beginning, they have been aggressively defending their product, instead of a more positive, active involvement in the Internet as it emerged. I believe there have been many opportunities for the recording industry that they let go to waste. Why should we have mercy for these folks.
I'm very disappointed. Many years ago when I still lived in Holland I talked to some people I knew in the industry (Polydor). I could see all these opportunities the Internet would bring, and I was pleased to hear they where actually quite on top of what was happening with the Internet. Unfortunately nothing good came out of that.
They have been hindering progress, and it almost sounds like they've just begun. The fact that I can order a CD on Amazon, even listen to samples, but CAN'T download the entire album is just ludicrous. But not being able to get the music on to my MP3 walkman because the CD is copy protected is plain insane.
Donating to the EFF and writing your congressmen is more important than ever.
For those that don't really understand the importance of preemptive multitasking (and from reading some comments, there are a few of you out there :-O), let's explain this through an example.
:-)
Consider application (a) that wants to read 128MB of data from the disk and application (b) that wants to read 1KB of data.
Let's say that the disk transfers @ 1MB/sec and let's assume application (a) issues the read 1 second before application (b) is started.
The sequence of calls for each app will look something like this:
1) program calls read
2) read is handled by the top level file system and is handed down to the proper file system
3) the file system calls the block device
4) the block device driver breaks up the request into the maximum block size the device can handle per request (for example 256 sectors for IDE)
5) for every request, the block device sends request to physical drive
6) drive transfers data to host
7) drive indicates 'done'
8) goto 5 until done
9) file system returns
10) read returns
It's important to know that there may be limitations on the number of requests any stage can handle simultaneously. For example, an IDE drive can only handle one request at a time. Some Operating Systems however introduce even tighter restrictions, because for example the block device driver was written, assuming only one request at a time would be allowed.
Take for example an OS where the kernel assures that no more that one request is pending between step 3) and 9).
This would have the following effect on our apps: app (a) is allowed to call step 4) because it is the first request. One second later, app (b) arrives at step 3) and is blocked. It is not allowed to enter step 4) until app (a) is done and passes step 9). Effectively this means that app (b) has to wait for 127 seconds before it gets access to step 4).
Now consider an OS where the file system and drivers can handle multiple requests. It still has to assure that the physical drive receives only one request though, so it permits only access of one app between step 5) and 7). App (a) arrives at step 5) first, so it gets to start sending requests to the drive. One second later, app (b) arrives at step 5) and has to wait for app (a) to finish it's current request to the drive. As soon as this request is done though, app (a) gets to step 8). Now we have both app (a) and app (b) wanting to have access to step 5). Depending on the scheduler either one will be granted access. There's a good change that app (b) will get access, and thus it only had to wait the time it took for app (a) to finish it's outstanding request, which takes max 1/8th of a second (256 sectors = 128KB) in this example.
Btw. you may notice though that there's more likely to be an (expensive) seek introduced by allowing app (b) to interrupt the transfer of app (a)
You can see how moving the 'lock' deeper in to the OS improves responsiveness. I'm not going to start a flame war about which OS is better, all I will say is that MY OS locks steps 5) through 7)
You mean a p2p walk-about?
No matter what, you can be sure that contrary to M$, these holes will be worked on 24/7 and fixed like yesterday. :)
I would have modded you down, but since you managed to squeeze in some nice and juicy, uncalled-for Microsoft bashing, I started doubting. And then I read:
Anyway, enjoy you uninformed, senseless bashing and flaming... trolls.
Wow, that did it, you didn't deserve to be modded down. That's a great troll! Thanks!
Digging deep into the history of slashdot, I found this poll [slashdot.org], which clearly indicates the vast majority does NOT want the moderation we have here today.
:o)
Been contradicting yourself much lately? Interesting use of 'deep into the history' and 'today' in one sentense.
I'll sacrifice my precious Karma to point that out.
What a blatant display of Karma-whoring!
/.? Sjeesh...
Before we know it, he's a moderator. I can't believe how cheap people are these days. Getting Microsoft all riled up for a little Karma on
Yes, it runs it as root.
.. are expanded. E.g. you can execute most anything,- consider for example argv[1] = "../../usr/sbin/bla > "
/usr/sbin/bla > /setup
/setup by just adding "../usr/../usr/../usr" (or plain whitespace may work too) until you overflow the buffer and have snprintf throw the rest away.
And like the guy says, if you can hijack the string (= argv[1]) you can execute almost any program as root.
Since popen hands this to a shell, things like
This would basically execute
If you want you can also remove the
In this case I don't know where argv[1] comes from, but it would have to be a very trustworthy source. In general it's fairly stupid to execute commands based on a parameter, especially as root.
I'm from the Netherlands, but in the US right now. The problem arose when I read the Palo Alto Daily about a week ago, where a professor was trying to explain how to use the 's.
:o)) I was never very good at foreign languages. In fact, not at my native language either.
/. so hopefully I have it down now. ;)
Ever since, I've been horribly confused.
Anyways, I read up on it, after my blunder here on
Ah, it's been confusing me a lot, but I think I get it now. Thanks.
I am not a native speaker, but doesn't:
An anonymous reader's submission linked to a PC which fits in your car's stereo slot
read like:
An anonymous reader is submission linked to a PC which fits in your car is stereo slot
??
Short version:
a) You give up your basic rights provided to you by the law.
b) Because this can't legally be done under the US law, you agree that we will put the law aside and have Borland make the rules.
I mean, are these guys still in kindergarten?? This is obviously an agreement that will not hold up in court. However, it should actually be illegal to even ask someone to agree with it. In a way Borland is asking us to agree to break the law.
It's sad to see that a company like Borland even TRIES something like that. Even if they fix their rediculous agreement, they owe the public a huge appology for taking us for such morons.
I actually thought Timmys comment I don't think it's quite as cool-looking as the Stereolink 1200 demonstrated quite well that we are not talking Golden Ears here.
:-)
It's amazing how many people buy their audio equipment based on looks. It somehow doesn't occur to them that the audio quality should be at least part of the consideration.
I remember trying to convince my mom to buy a certain stereo because it sounded good (for the money). She replied: yeah, but THAT one LOOKS better. The fact that the sound it produced was horrible didn't weigh in very much.
Well, actually, right now there's also '\n's.
Which actually gives us a hint on where to start with decoding: there's an obvious pattern, however, the length chosen for the lines is not identical to the pattern.
In other words, first thing to do is rearranging the line lenghts to match the pattern.
If I take the random piece:
00001000000001100000000000000000000000000
00000000000000000000000000000000000000000
00000000000000000000000000000000000000000
00000000000000000110000000000000000000000
00000000000000000000000000000000000000000
00000000000000000000000000000000000000000
00000000000000000000011000000000000110011
00100010001001010010001000100000001010000
00000000000011000100110000001000000101001
00100001000100001100000000100000000000011
00010000000001010010010101010010000001100
I would rearrange it as:
00001000000001100000000000000000000000000*
00000000000001100000000000000000000000000*
00000000000001100000000000011001100100010*
00001100000000100000000000011000100000000*
(*end of line cut due to lameness filter)
The noise is obvious from the fourth line. It becomes a bit trick if you get noise in the time-domain, but still nothing to complex. It certainly looks like they use a fixed 'word' length.
years of work in transferring data off 140-some 10" magnetic tapes
;)
That means at least one person spent several DAYS PER TAPE???
Even punch tape 'd faster than that.
It's still vapor right now for sure
I know a guy that works there. He's been VERY secretive about what they where doing.
But what I do know is that they have been working on this for a long time. They've had several revisions of hardware.
I understand some think this is vapor because it seems to just have popped up. But it's not nearly as vapor as you may think.
And exactly how much would you want to pay for one?
It's easy enough for me to go over and put a bid on a couple. I could practically walk there.
If there are people that are seriously interested, let me know. I suspect there will be more bidders on these boxen though. I don't care to make money on them, and I don't mind paying for them in advance, I just need to get an idea of what people would want to realistically pay for them.
nothing will go on the cheap.
/.ed as the site.
I wonder if the auction itself is going to be as
Unfortunately, most of the stuff is just nothing-fancy standard office equipment. Be wasn't living the hi-life like the dotcoms. It's too bad they didn't make it.
You can read up on it at this site for example.
Hmm, in fact this ran that article.
I don't think Stanford actually filed a lawsuit, but they where pretty close.
Yeah, that statement annoyed me a lot too.
:o)
The poster seems to assume that all India and China has to offer in terms of software development is programming houses that provide services to US companies.
Although it's almost impossible to avoid any racist issues when discussing this matter, I do believe the use of these houses is a Good Thing.
First of all, it provides a way to distribute money from the US to countries that have a lower standard of living. Secondly, it promotes education. The combination of the two has proven to be very succesful in increasing the standard of living in places that need it.
In fact, much of the great free software we all use has non-US origins.
In fact, some of the not so great, not so free software was made in the US.
Thanks, that's indeed insightful.
;o))
Could you or anyone else that has good experience with these type of companies provide some details of those companies (website).
We have never outsourced our coding but we are certainly interested. There is some fear to overcome with management though. We have never had our source go outside the building for example (yep, closed source, for good reasons, believe me) so sending it overseas is not something that they'll do easily. And in our case we probably would have to do that.
It's basically a trust issue, so one of the best ways to start off is with a company that comes highly recommended. (Instead of replying to spam
So anyone: bring em on!