You should use them where they're appropiate. For some things they're great, and in general I think using stored procedures and views for even simple things can bring great flexibility. For example it can be convenient to be able to fix bugs by changing stored procedures instead of distributing a new version of the program, and it helps writing good code too. Things look much nicer when the executable does the interface stuff and doesn't consist of lots of embedded SQL.
Also, they can bring huge performance benefits. For example, by turning the function that calculated an article's price (which depends on client, which may have VAT apply or not, may be discounted or not, etc) to a stored procedure.
The intent of the function was to get the final price. By retrieving such things as rows from the client and discount tables you're introducing unneeded latencies into your program which will now have to wait while this data gets delivered, used, and then almost certainly forgotten unless you implement some kind of cache.
By keeping all this stuff on the database server and only sending the result to the client you save bandwidth and time. My rewritten function executes more than 10 times faster than the original written in VB using ADO. By the way, if you really want to get the maximum performance possible in VB, first move the code to a stored procedure, then write a VB wrapper that caches the Command object. Turns out creating ADO objects is quite noticeably expensive.
I'd say the main considerations are:
Are you getting things from the database you will forget soon? If you will be retrieving data from the database to only use it temporarily in a complicated operation to forget it later, then it's probably better to avoid making it go through the network at all, so use a stored procedure.
Are you writing code with lots of SQL? If so, it'll look much prettier in a stored procedure than as a mess of string concatenation in whatever language you use.
Are you passing complicated data types? If whatever you're sending to the database is going to contain quotes, floating point numbers or dates, it might be safer to put the code in a stored procedure and call it with ADO or whatever you use so that it deals for you with issues like quotes in strings and date formats. Sure you can do that by hand, but it's very easy to try to send a number as a string by converting it with str(), forgetting that in some countries the decimal separator is a comma, and the SQL server won't like that.
Big, fixed queries probably can be safely moved to stored procedures and views too, just because huge joins that fill the whole page are often messy and distract from the main thing.
Now, one thing that should definitely go in the application is interface related code. I'd avoid excessive sanity checking in stored procedures, since that's often much better done in the interface, and some types of user permissions would belong there as well.
Also, big loops almost always should go in the program. Your server probably supports the use of cursors in stored procedures, but that has pretty high chances of freezing your application for a long amount of time with no progress report, and makes error handling more difficult.
Sure, it'll make things a bit harder, but looking for strings in a binary isn't exactly difficult, and any attempts to make it undebuggable won't really give a huge advantage since anything that gets executed can get traced given enough effort
I used to have one, but it caused BIG problems in combination with the VIA chipset on my Duron 850. It took me weeks to finally realize it was the card because crashes were very random. So I gave it to my brother, who was pretty happy with it.
Later I bought a dual Athlon MP, and gave the Duron to my brother. I had already heard Creative drivers don't work on SMP. Then I spent all day trying to install Win2K on the Duron, until I finally realized it was the old chipset problem.
So, we ended without being able to use it on any computer. I told my brother that probably the best thing to do with it is to give it as a gift to somebody he didn't like;-)
For the Athlon I bought a Terratec DMX X-Fire 1024, which works perfectly fine with SMP in both Linux and Windows. On Linux it also supports several hardware channels, so/dev/dsp can be opened more than once for example.
My current best guess for that is aimed at situations where I'm available. Errors try to be at least somewhat informative for the user, giving an approximate description and recomendation, then a message for the programmer. The whole message is logged.
The error message on Windows would look like this:
Serious error while trying to save order. The current changes will have been lost. A program restart is recommended.
Please call [programmer] with the following information: Error #43 in SaveOrderRow: Statement failed...
Or this:
Slight problem while trying to get statistics. The program should continue working, but not all information may have been retrieved.
The message will be logged, [programmer] will find about it. Call the programmer only if the problem is urgent. Error #55 in GetOrderCount: The stored procedure 'sp_count_orders' has returned an error...
The simple solution for that would be to use all RAWs for your modification, and then save as JPG. Then there will not be artifacts out of place, and additionally JPEG compression will probably hide small mistakes you make with photoshop.
I suppose that if somebody seriously wants to falsify evidence, they'd at least spend some effort on doing it well.
They work when somebody actually spends some time on properly testing them.
I bought Neverwinter Nights and the first expansion recently. The CD key on the NWN package is printed with absolutely worst font ever. 'A' and 'R', and 'D', '0' and 'O' look the same. Took me about 16 tries to finally get it right.
Fortunately, the expansion had a saner font, but then it turned out they forgot to package the ambient sounds on the CD.
Linux libraries work exactly the same as Windows variants, except that you can install more than one version of the same library at the same time.
Of course, a library can also change in an incompatible way, but programmers bump the major version, so that the old version and the apps linked against it can be kept, and I've never seen it done for security/bug fixes.
The way I understood is that they're switching to a Debian-like model, where new stuff gets added to unstable, and after some time passes to testing. This doesn't have to be problematic, I used Debian testing for years, and never had problems despite it having much more code than the Linux kernel.
The improvement I hope to see from this is experimental drivers. Having drivers for VIA motherboards added into the mainstream kernel and clearly marked as EXPERIMENTAL will not hurt anybody, and lower the amount of work necessary to get the desired functionality. It should also reduce the amount of time the maintainers of the experimental features have to spent to adapt their code to new kernel versions.
Well, if things were economically that bad, then it sounds like the company would have gone bankrupt sooner or later anyway. After 20 years without profits it must have been in real problems already, and if one week of downtime was enough to go under, then probably the end was quite near.
Well, that indeed sounds like a rather bad case of bad luck then...
> I thought it was funny that the first guy that e-mailed me back assumed I was running a Usenet news server when I mentioned the # of files.
Well, it's one of the main uses. ReiserFS works best with large amounts of small files, which mainly means mail and news servers. I have recently seen that in practice. I'm preparing a new Gentoo server here, and tried rsyncing against it when it had/usr/portage first on ReiserFS and then on XFS. ReiserFS performance is just amazing when compared with XFS in that case. I've heard XFS is somewhat better for large files though.
> Thanks for explaining that. I've always wondered why mounting a reiserfs drive always took so longer after a crash. It was doing an fsck.
It's kind of that, yeah. Simple systems like ext2 end in an inconsistent state after say, the power goes out, and need an external tool to fix it. Journalling filesystems like reiserfs and ext3 keep something like a change log, which they can use to roll back the system to a good state during boot, without needing to do things like scanning the whole disk.
Have in mind though that by default reiserfs only journals metadata. It means that in case of an unexpected shutdown you're not going to end with problems like unknown data floating around the disk that gets linked in lost&found, or files having the wrong size/attributes/etc.
However, if you had an incomplete change to a file it's going to remain that way. You can enable full data journalling, but that has a quite noticeable performance penalty. ReiserFS 4 seems to be quite similar to a database as it lets you start, commit and rollback transactions, which sounds really nice. Haven't got around trying it yet though, and it's currently unstable.
Well, I've seen one company (25 employees or so) that has a database that's about 300 MB in size, and that's too big already due to accumulated cruft and lack of proper normalization. I just meant that having the data backed up in some format that's easy to read would have really helped.
One thing I don't get is how did your two backup servers fail. It's just strange that they'd spend there possibly months quietly writing your data to disk and then failing to read it back. In that respect, some proper testing might have helped.
Mind you, I understand that ReiserFS is problematic. I had problems with it myself when I moved to 2.4, and needed to reiserfsck a few times. But from what I've seen, the reiserfs people are really helpful, and respond to questions very fast, so your situation sounds also rather strange.
I also was somewhat surprised at how reiserfsck worked, but after looking at the mailing list got a pretty good explanation. In filesystems like ext2, the fsck tool is part of the filesystem design, since it can't ensure its own integrity without extra help. ReiserFS, on the other hand, is designed to be always consistent, so if reiserfsck is needed at all that means it's a bug in reiserfs or disk damage. So, reiserfsck is intentionally hard to run, because they don't want you to do that. Ideally, you shouldn't need it at all. It's an emergency repair tool. You probably should send mail to the reiserfs list before using it at all, unless it's a known problem. I've seen that they will sometimes make patches for it, and ask people to try them.
Either something is wrong here or you've got a serious lack of sysadmin skills.
If your company is in danger of going out of business, and you don't know how to fix it, one thing you don't do is sit there and mess with things you don't know enough about. You go and email the reiserfs and LVM people. Both are well maintained. Given Linux's open source nature, you could even try to look for a programmer that worked on the kernel. That option probably wouldn't have been very cheap, but it'd sure beat going out of business.
The ReiserFS developers will offer support for free if it was their fault. If it was your, pay them, and they'll help. And btw, you should have backups on removable media. Tapes, DVDs, etc.
Well, I did have a small problem with dm-crypt, but that was a new feature when I tried it, and an email to the maintainer quickly solved it.
Of course it's a bug, but I wouldn't say it's on the same level as the reiserfs mess in 2.4. This is probably used by few people, and the bug only manifested with highmem enabled.
The core functionality of 2.6 didn't give me any problems at all, unlike 2.4. This is something I actually like to see. I don't mind if heaps of experimental stuff is added to 2.6, as long as they're things that have to be enabled. I definitely welcome things like experimental drivers for new hardware.
So far for me, 2.6 is turning out to be pretty stable, and I switched to it quite early, starting with 2.6.3 I think. In comparison, 2.4.3 was really bad. It was almost a miracle that I managed to avoid critical data loss after switching to 2.4.0 and using ReiserFS on my root partition.
2.6 so far just works and that's it. Maybe there's some lack of polish somewhere, but so far it works fine here on SMP.
"Wow, great project!". It was like Freenet, only faster, lower latency, some stuff was cooler. It looked really promising. It was much easier to install in a chroot jail than Freenet.
However. From what I saw, I wouldn't trust it for any serious purpose. It looked like the author was only interested in using it for testing his own crypto algorithms, and as anybody who read on this stuff should know, rolling your own crypto is a really bad idea unless you're really, really good, and then make sure it gets well tested for a few years.
It had a nice possibility of restricting the node to chosen allowed crypto algorithms, but none of the available ones was in widespread use. I mean, AES, DES and Blowfish weren't in the list last time I checked. That makes me rather suspicious.
I voiced my concerns once in the Entropy forum, and the author replied saying this is basically a research project and not intended for serious use (IIRC).
If somebody does decide to continue with it, I certainly hope that one of the first things that will be done is to put some tested crypto in it instead of a bunch of homebrew methods. Nothing personal against the author, but I believe that if it was easier to trust it, it could become more popular.
Of course, I'm not saying SMART predicts all disk failures. But it does help a lot, and it's quite effective at avoiding those nasty situations where you find that your hard disk has been remapping sectors for the last week, and just happened to run out of them.
Any important server should be on a decent UPS as well, which should reduce considerably the probability of a spike frying the hard disk.
Now, sure you still have head crashes and controller failure, but if head crashes are accounted for with RAID, I'd say the overall reliability could be pretty good.
BTW, why do I keep hearing people talk about controller failure? Surely controllers located in an air conditioned data center with clean power don't have that high chances of suddenly breaking for no reason?
I think there should be a law that says that every time somebody says that bugless programs don't exist, somebody will try to refute that by posting a Hello World program that doesn't work.
True, for that you'd need to take more complicated measures. Although not always. For example, some small companies close at night, and can perfectly allow shutting down the database for a few seconds to create a snapshot.
I mostly deal with mail servers here, and for that snapshots should work just fine in most cases.
It's the part of the OS that determines what task to run.
The problem is this: You want to run tasks A, B, and C, and need to do it in the most optimal way possible.
The simplest way is FIFO, like say, DOS. If A starts first, then A runs until completion, then B starts. This is bad for many reasons, like that if A gets stuck for any reason nothing gets done, and that while A is waiting for input the free resources can't be used for anything else.
A simple way of multitasking would be simply alternating between A, B and C every fixed interval. But that's not very good either, perhaps B doesn't need to do any processing now, and only wastes time, while C could really use that.
A better way is to do it by priorities, but then you need to find a good way of calculating this priority.
One of the reasons there's so much talk about them is that most become slower when you have more tasks. Most of the simple ones need to examine every running task to determine what should run now, and if you want to launch 10000 processes at once, that's not good. O(1) schedulers are a solution for that, because they use algorithms that always take the same amount of time to execute, irregardless of whether there's 3 or 10000 tasks. That doesn't mean a simpler scheduler wouldn't work faster for 10 tasks, though.
The other problem is how to determine how to distribute CPU time. Say, for servers you mostly want fast and fair3o determine which processes are interactive, and which are on the background and won't mind some interruption.
Well, actually, you can monitor hard disks very well if you know how.
SMART gives quite a lot of info, including things like temperature, read error rate, how much it needed to ECC correct something, how often the data coming from the IDE cable was corrupted, and of course the number of remapped sectors.
So you don't have to wait until the drive runs out of spare sectors to find something is wrong with it.
The idea is to try to set up a mail/web server that turns off the hard disk at night. Mail would get delivered to flash, then moved to the hard disk during the day. The mini-linux system that will run from Flash is almost done, next I will be writing a PAM module, so that when somebody checks the mail it's automatically moved to the hard disk.
So it's still possible the hard disk will go on once in a while, but it should be silent most of the time. The UPS should be quite happy with that as well.
Slashdot Mirror
You should use them where they're appropiate. For some things they're great, and in general I think using stored procedures and views for even simple things can bring great flexibility. For example it can be convenient to be able to fix bugs by changing stored procedures instead of distributing a new version of the program, and it helps writing good code too. Things look much nicer when the executable does the interface stuff and doesn't consist of lots of embedded SQL.
Also, they can bring huge performance benefits. For example, by turning the function that calculated an article's price (which depends on client, which may have VAT apply or not, may be discounted or not, etc) to a stored procedure.
The intent of the function was to get the final price. By retrieving such things as rows from the client and discount tables you're introducing unneeded latencies into your program which will now have to wait while this data gets delivered, used, and then almost certainly forgotten unless you implement some kind of cache.
By keeping all this stuff on the database server and only sending the result to the client you save bandwidth and time. My rewritten function executes more than 10 times faster than the original written in VB using ADO. By the way, if you really want to get the maximum performance possible in VB, first move the code to a stored procedure, then write a VB wrapper that caches the Command object. Turns out creating ADO objects is quite noticeably expensive.
I'd say the main considerations are:
Are you getting things from the database you will forget soon? If you will be retrieving data from the database to only use it temporarily in a complicated operation to forget it later, then it's probably better to avoid making it go through the network at all, so use a stored procedure.
Are you writing code with lots of SQL? If so, it'll look much prettier in a stored procedure than as a mess of string concatenation in whatever language you use.
Are you passing complicated data types? If whatever you're sending to the database is going to contain quotes, floating point numbers or dates, it might be safer to put the code in a stored procedure and call it with ADO or whatever you use so that it deals for you with issues like quotes in strings and date formats. Sure you can do that by hand, but it's very easy to try to send a number as a string by converting it with str(), forgetting that in some countries the decimal separator is a comma, and the SQL server won't like that.
Big, fixed queries probably can be safely moved to stored procedures and views too, just because huge joins that fill the whole page are often messy and distract from the main thing.
Now, one thing that should definitely go in the application is interface related code. I'd avoid excessive sanity checking in stored procedures, since that's often much better done in the interface, and some types of user permissions would belong there as well.
Also, big loops almost always should go in the program. Your server probably supports the use of cursors in stored procedures, but that has pretty high chances of freezing your application for a long amount of time with no progress report, and makes error handling more difficult.
Won't help
Sure, it'll make things a bit harder, but looking for strings in a binary isn't exactly difficult, and any attempts to make it undebuggable won't really give a huge advantage since anything that gets executed can get traced given enough effort
That's why I no longer have a SB Live here.
;-)
/dev/dsp can be opened more than once for example.
I used to have one, but it caused BIG problems in combination with the VIA chipset on my Duron 850. It took me weeks to finally realize it was the card because crashes were very random. So I gave it to my brother, who was pretty happy with it.
Later I bought a dual Athlon MP, and gave the Duron to my brother. I had already heard Creative drivers don't work on SMP. Then I spent all day trying to install Win2K on the Duron, until I finally realized it was the old chipset problem.
So, we ended without being able to use it on any computer. I told my brother that probably the best thing to do with it is to give it as a gift to somebody he didn't like
For the Athlon I bought a Terratec DMX X-Fire 1024, which works perfectly fine with SMP in both Linux and Windows. On Linux it also supports several hardware channels, so
My current best guess for that is aimed at situations where I'm available. Errors try to be at least somewhat informative for the user, giving an approximate description and recomendation, then a message for the programmer. The whole message is logged.
...
...
The error message on Windows would look like this:
Serious error while trying to save order. The current changes will have been lost. A program restart is recommended.
Please call [programmer] with the following information:
Error #43 in SaveOrderRow: Statement failed
Or this:
Slight problem while trying to get statistics. The program should continue working, but not all information may have been retrieved.
The message will be logged, [programmer] will find about it. Call the programmer only if the problem is urgent.
Error #55 in GetOrderCount: The stored procedure 'sp_count_orders' has returned an error
The simple solution for that would be to use all RAWs for your modification, and then save as JPG. Then there will not be artifacts out of place, and additionally JPEG compression will probably hide small mistakes you make with photoshop.
I suppose that if somebody seriously wants to falsify evidence, they'd at least spend some effort on doing it well.
They work when somebody actually spends some time on properly testing them.
I bought Neverwinter Nights and the first expansion recently. The CD key on the NWN package is printed with absolutely worst font ever. 'A' and 'R', and 'D', '0' and 'O' look the same. Took me about 16 tries to finally get it right.
Fortunately, the expansion had a saner font, but then it turned out they forgot to package the ambient sounds on the CD.
Huh? What's this about recompiling?
Linux libraries work exactly the same as Windows variants, except that you can install more than one version of the same library at the same time.
Of course, a library can also change in an incompatible way, but programmers bump the major version, so that the old version and the apps linked against it can be kept, and I've never seen it done for security/bug fixes.
Doesn't have to necessarily break horrible.
The way I understood is that they're switching to a Debian-like model, where new stuff gets added to unstable, and after some time passes to testing. This doesn't have to be problematic, I used Debian testing for years, and never had problems despite it having much more code than the Linux kernel.
The improvement I hope to see from this is experimental drivers. Having drivers for VIA motherboards added into the mainstream kernel and clearly marked as EXPERIMENTAL will not hurt anybody, and lower the amount of work necessary to get the desired functionality. It should also reduce the amount of time the maintainers of the experimental features have to spent to adapt their code to new kernel versions.
Well, if things were economically that bad, then it sounds like the company would have gone bankrupt sooner or later anyway. After 20 years without profits it must have been in real problems already, and if one week of downtime was enough to go under, then probably the end was quite near.
Well, that indeed sounds like a rather bad case of bad luck then...
/usr/portage first on ReiserFS and then on XFS. ReiserFS performance is just amazing when compared with XFS in that case. I've heard XFS is somewhat better for large files though.
> I thought it was funny that the first guy that e-mailed me back assumed I was running a Usenet news server when I mentioned the # of files.
Well, it's one of the main uses. ReiserFS works best with large amounts of small files, which mainly means mail and news servers. I have recently seen that in practice. I'm preparing a new Gentoo server here, and tried rsyncing against it when it had
> Thanks for explaining that. I've always wondered why mounting a reiserfs drive always took so longer after a crash. It was doing an fsck.
It's kind of that, yeah. Simple systems like ext2 end in an inconsistent state after say, the power goes out, and need an external tool to fix it. Journalling filesystems like reiserfs and ext3 keep something like a change log, which they can use to roll back the system to a good state during boot, without needing to do things like scanning the whole disk.
Have in mind though that by default reiserfs only journals metadata. It means that in case of an unexpected shutdown you're not going to end with problems like unknown data floating around the disk that gets linked in lost&found, or files having the wrong size/attributes/etc.
However, if you had an incomplete change to a file it's going to remain that way. You can enable full data journalling, but that has a quite noticeable performance penalty. ReiserFS 4 seems to be quite similar to a database as it lets you start, commit and rollback transactions, which sounds really nice. Haven't got around trying it yet though, and it's currently unstable.
Well, I've seen one company (25 employees or so) that has a database that's about 300 MB in size, and that's too big already due to accumulated cruft and lack of proper normalization. I just meant that having the data backed up in some format that's easy to read would have really helped.
One thing I don't get is how did your two backup servers fail. It's just strange that they'd spend there possibly months quietly writing your data to disk and then failing to read it back. In that respect, some proper testing might have helped.
Mind you, I understand that ReiserFS is problematic. I had problems with it myself when I moved to 2.4, and needed to reiserfsck a few times. But from what I've seen, the reiserfs people are really helpful, and respond to questions very fast, so your situation sounds also rather strange.
I also was somewhat surprised at how reiserfsck worked, but after looking at the mailing list got a pretty good explanation. In filesystems like ext2, the fsck tool is part of the filesystem design, since it can't ensure its own integrity without extra help. ReiserFS, on the other hand, is designed to be always consistent, so if reiserfsck is needed at all that means it's a bug in reiserfs or disk damage. So, reiserfsck is intentionally hard to run, because they don't want you to do that. Ideally, you shouldn't need it at all. It's an emergency repair tool. You probably should send mail to the reiserfs list before using it at all, unless it's a known problem. I've seen that they will sometimes make patches for it, and ask people to try them.
Either something is wrong here or you've got a serious lack of sysadmin skills.
If your company is in danger of going out of business, and you don't know how to fix it, one thing you don't do is sit there and mess with things you don't know enough about. You go and email the reiserfs and LVM people. Both are well maintained. Given Linux's open source nature, you could even try to look for a programmer that worked on the kernel. That option probably wouldn't have been very cheap, but it'd sure beat going out of business.
The ReiserFS developers will offer support for free if it was their fault. If it was your, pay them, and they'll help. And btw, you should have backups on removable media. Tapes, DVDs, etc.
Well, I did have a small problem with dm-crypt, but that was a new feature when I tried it, and an email to the maintainer quickly solved it.
Of course it's a bug, but I wouldn't say it's on the same level as the reiserfs mess in 2.4. This is probably used by few people, and the bug only manifested with highmem enabled.
The core functionality of 2.6 didn't give me any problems at all, unlike 2.4. This is something I actually like to see. I don't mind if heaps of experimental stuff is added to 2.6, as long as they're things that have to be enabled. I definitely welcome things like experimental drivers for new hardware.
Please explain?
So far for me, 2.6 is turning out to be pretty stable, and I switched to it quite early, starting with 2.6.3 I think. In comparison, 2.4.3 was really bad. It was almost a miracle that I managed to avoid critical data loss after switching to 2.4.0 and using ReiserFS on my root partition.
2.6 so far just works and that's it. Maybe there's some lack of polish somewhere, but so far it works fine here on SMP.
I'd say neither.
Remember, the enemy of your enemy is not always your friend.
Okay, first impression was:
"Wow, great project!". It was like Freenet, only faster, lower latency, some stuff was cooler. It looked really promising. It was much easier to install in a chroot jail than Freenet.
However. From what I saw, I wouldn't trust it for any serious purpose. It looked like the author was only interested in using it for testing his own crypto algorithms, and as anybody who read on this stuff should know, rolling your own crypto is a really bad idea unless you're really, really good, and then make sure it gets well tested for a few years.
It had a nice possibility of restricting the node to chosen allowed crypto algorithms, but none of the available ones was in widespread use. I mean, AES, DES and Blowfish weren't in the list last time I checked. That makes me rather suspicious.
I voiced my concerns once in the Entropy forum, and the author replied saying this is basically a research project and not intended for serious use (IIRC).
If somebody does decide to continue with it, I certainly hope that one of the first things that will be done is to put some tested crypto in it instead of a bunch of homebrew methods. Nothing personal against the author, but I believe that if it was easier to trust it, it could become more popular.
Of course, I'm not saying SMART predicts all disk failures. But it does help a lot, and it's quite effective at avoiding those nasty situations where you find that your hard disk has been remapping sectors for the last week, and just happened to run out of them.
Any important server should be on a decent UPS as well, which should reduce considerably the probability of a spike frying the hard disk.
Now, sure you still have head crashes and controller failure, but if head crashes are accounted for with RAID, I'd say the overall reliability could be pretty good.
BTW, why do I keep hearing people talk about controller failure? Surely controllers located in an air conditioned data center with clean power don't have that high chances of suddenly breaking for no reason?
I think I'll have to submit a KDE bug then, Konqueror's (it says it should be "Conqueror's"!) spell checker didn't complain about that.
I think there should be a law that says that every time somebody says that bugless programs don't exist, somebody will try to refute that by posting a Hello World program that doesn't work.
True, for that you'd need to take more complicated measures. Although not always. For example, some small companies close at night, and can perfectly allow shutting down the database for a few seconds to create a snapshot.
I mostly deal with mail servers here, and for that snapshots should work just fine in most cases.
It's the part of the OS that determines what task to run.
The problem is this: You want to run tasks A, B, and C, and need to do it in the most optimal way possible.
The simplest way is FIFO, like say, DOS. If A starts first, then A runs until completion, then B starts. This is bad for many reasons, like that if A gets stuck for any reason nothing gets done, and that while A is waiting for input the free resources can't be used for anything else.
A simple way of multitasking would be simply alternating between A, B and C every fixed interval. But that's not very good either, perhaps B doesn't need to do any processing now, and only wastes time, while C could really use that.
A better way is to do it by priorities, but then you need to find a good way of calculating this priority.
One of the reasons there's so much talk about them is that most become slower when you have more tasks. Most of the simple ones need to examine every running task to determine what should run now, and if you want to launch 10000 processes at once, that's not good. O(1) schedulers are a solution for that, because they use algorithms that always take the same amount of time to execute, irregardless of whether there's 3 or 10000 tasks. That doesn't mean a simpler scheduler wouldn't work faster for 10 tasks, though.
The other problem is how to determine how to distribute CPU time. Say, for servers you mostly want fast and fair3o determine which processes are interactive, and which are on the background and won't mind some interruption.
Well, actually, you can monitor hard disks very well if you know how.
SMART gives quite a lot of info, including things like temperature, read error rate, how much it needed to ECC correct something, how often the data coming from the IDE cable was corrupted, and of course the number of remapped sectors.
So you don't have to wait until the drive runs out of spare sectors to find something is wrong with it.
Or, if you run Linux, just use LVM and snapshots. It's free (as in beer).
"End If" contains useful information though. In C you sometimes see things like:
/* if (foo == bar) */
}
because lots of {s and }s get confusing pretty fast
I'm trying to do this right now.
The idea is to try to set up a mail/web server that turns off the hard disk at night. Mail would get delivered to flash, then moved to the hard disk during the day. The mini-linux system that will run from Flash is almost done, next I will be writing a PAM module, so that when somebody checks the mail it's automatically moved to the hard disk.
So it's still possible the hard disk will go on once in a while, but it should be silent most of the time. The UPS should be quite happy with that as well.