It depends on the filter... I use numerous RBL databases in addition to blocking various countries (i.e. China, Russia, Nigeria, etc.). Just this step alone blocks most spam. In fact, it might be working too well since there's not enough left to effectively run the Bayes filters.
RBL filters consume very little in terms of CPU since it's all basically DNS lookups. It also prevents the spam payload from ever entering the mail server. There's other things I do with Postfix that turns my mail server into a tarpit for spammers. It also makes dictionary attacks of user names impossible while consuming very little bandwidth. Basically it holds onto the connection to the mail server and waits a predetermined amount of time before responding with an error code (i.e. 45 seconds). Note that some RBL filters are better than others, and some block legitimate sites.
Since I run my own mail server and don't know anyone in Russia or China, I can effectively block the entire countries (see blackhole.us).
Challenge response does not work well. In my case, there is a spammer out there who uses random email addresses at my domain name. Every time he sends a spam run I get anywhere from tens of thousands to over a hundred thousand bounced emails at my mail server. This server is for personal use only and is not designed to handle huge amounts of email, though Postfix doesn't seem to mind too much even though it's a 333MHz Pentium II box running Linux (uptime now at 595 days).
While my mail server doesn't seem to mind too much (other than huge log files), my Netgear firewall goes nuts from time to time forcing me to reboot it.
What would stop this type of DDOS I'm under? The gateway mail server should validate the recipient and return an error code right away instead of sending a bounced email later.
No Child Left Behind is a serious failure and is hurting some of our best schools. Here in the San Francisco Bay Area, some of the best schools in the nation, i.e. Cupertino, are being punished because the schools are being labeled as failing under the federal law. The law requires schools show continuous improvement, but as schools get better and better, this becomes more difficult to do. In the case of some of the school districts here in CA, it's due to too many students not taking the test. Apparently parents have the option of not letting their kids take the test, mostly for special ed. It's stupid to require some of these kids to take the tests. Some of the special ed. students are not much more than vegetables or cannot read due to mental disability.
Also, at least in the good schools around here it is often quite competitive and there is strong parent involvement. Part of it is that parents are willing to pay a premium when buying homes in the good school districts.
When I patched my SuSE X server with a Gentoo patch to use the new event mechanism I was pleasantly surprised to see that the tilt support worked in KDE applications. (it does not work in Firefox, BTW). Now I just wish the X protocol could be fixed to support more than 7 buttons, since I can only support the usual 3 buttons and vertical and horizontal scrolling. I wish I could assign other buttons as well on my Logitech MX1000.
Apparently there's experimental support for the PCTV HD-3000 card. This card supports NTSC, ATSC, and QAM. Unfortunately there's not much you can do with the encrypted signals. Apparently Comcast transmits all digital channels as encrypted except for the local stations. I have not personally tried the QAM support since it's currently a set of experimental patches against the latest driver code.
-Aaron
Didn't SP2 make it impossible in Windows for an application to fill in an invalid source IP address? If this is the case, I wonder if this problem cropped up because Microsoft cannot generate the LAND attack with an up to date version of their OS.
Also, I wonder what sort of vulnerabilities exist in Windows for IPv6?
If you're setting the time every hour, it would probably be next to impossible to measure the drift since it will be so small and get lost in the normal packet jitter.
Also, at least some operating systems have the ability to detect drift from running NTP and can correct accordingly.
Back when I had an old Nokia cellphone for work (which I conveniently lost) I went through all the various ringtones it had trying to find the least obnoxious one. I finally found one that slowly increased to get your attention. The first ring was vibrate only, followed by a very short beep. The longer I waited the more insistant the ring became. I thought this was a good compromise. I think they should focus on finding the least annoying ringtones possible. But out of all the various ringtone combinations it had, it only had one clearly designed to be as unobtrusive as possible. This phone was before all the new polyphonic ringtones which now are so pervasive.
I rarely miss my cellphone since I misplaced it and let the battery run down over a year ago.
In terms of optimizing, generally compilers do a pretty good job, however there are several areas that no compiler I know of can help.
1. Choose the right algorithm. For example, in an embedded project I worked on an engineer used a linked list to store thousands of fields that must be added and deleted. While adding is fast, it didn't scale for deleting. Changed it to a hash table and it sped it up significantly.
2. Know your data and how it is used. Knowing how to organize your data and access it can make a huge difference. As a previous poster pointed out, sequential memory accesses are much faster than random accesses. I had to do some 90 degree image rotation code. The simple solution just used a couple for loops when copying the pixels from one buffer to another. In another, I took into account the processor cache and how memory is accessed and broke it down into tiles. The first algorithm, while simple and elegant ran at 30 frames per second. The other ran at over 200 frames per second. Looking at the code the first algorithm should be faster since the code is simpler. Both algorithms operate in O(N) time, where N=width * height.
Further optimization attempts to hint to the CPU cache about memory made no difference (Athlon XP 1700+). The only possible way I see to speed it up further would be to write it in hand-coded assembler.
3. Reduce the number of system calls if possible. Some operating systems can be very painful when calling the kernel. Group reads and writes together so fewer calls are made.
4. Profile your code to find bottlenecks.
5. Try and keep a tradeoff between memory usage and performance. A smaller tightly packed data set will execute faster with CPU caches and will reduce page faults when loading and starting up.
6. Try debugging your code at the assembler level, stepping through it. It will help you better understand your compiler.
7. Don't bother trying to optimize things like getting every ounce of performance when the next function you call will be very slow. I.e. in one section of MS DOS's source code which was hand-coded assembly language it was calculating the cluster or sector of the disk to access. First the code checked if it was running on a 16-bit or 32-bit CPU. Next it took the 16-bit or 32-bit path for multiplication, then it read from the disk. Why the hell write all this code to check the CPU if it's 16 or 32 bit for the multiply when the frigging disk is going to be slow. They should have just stuck with the 16-bit multiply rather than be clever.
In general applications with GCC, I rarely see much difference between -O2 or -O3. For that matter, I often don't see a noticable difference between -O0 and -O3 for a lot of code.
I only see improvements in some very CPU intensive multimedia code. I also saw a significant improvement in some multimedia code when I told the compiler to generate code for an Ultrasparc rather than the default, but that's because the pre-ultrasparc code didn't use a multiply instruction.
This created a 28977 byte ogg file of silence with a play time of 1 minute, 3 seconds. Note that this is a very high quality stereophonic file with a 192KHz sample rate and 16 bits per sample (oggenc doesn't seem to like more than 16 bits/sample or more than 2 channels).
Of course, I'm sure there's probably a way to do this in a single line, or you can skip the second step and just share the PCM file.
As someone who writes firmware that runs on a network processor, I can attest that the networking hardware is usually very different. For example, although the network processor runs at a lowly 133MHz it is able to forward 1.5 million packets/second when performing basic routing. I don't think there's any way a traditional processor could keep up. For one, the network processor has a massive amount of memory bandwidth and low latency, using SRAM for the tables. Other network processors use content addressable memory. To give an idea of memory bandwidth, one of the network processors I'm looking closely at has 11 separate memory interfaces to the chip, a mix of SRAM and DRAM.
Most of the work in the router is pattern matching, with a lot of lookups of various parts of the packet. The route lookup is actually one of the least expensive operations compared to all of the other operations that need to take place. Most of the high-end network processors have dedicated pattern matching hardware to speed up these operations and do not rely on caches which break when a lot of flows are active.
One operation we found to be very painful in a traditional processor is trying to shape traffic, i.e. using the Linux shaping options. Dedicated hardware, on the other hand, has no problems with this.
Now, I doubt many of these features would help much in a workstation or server. The only thing I can think of that would help significantly is some of the security operations, like being able to do offload encryption or do ACL lookups in hardware, much like how NVidia does this in their new NForce chipset. ACLs tend to be very expensive in terms of CPU cycles.
One big advantage Sony has over Microsoft in the case of the PS3 is that Sony makes their own ASICs and can probably include them in the PS3 at cost. Microsoft has no such advantage. They must pay for the CPU and graphics chip which you can be sure will not be sold at a loss from the suppliers (i.e. ATI).
When you make your own ASICs, your cost for mass production are typically much lower than if you buy off the shelf parts, even if you pay someone else to make the parts for you.
By not making their own silicon, Microsoft is at a disadvantage, just like how now they must pay Intel and NVidia for every XBox 2 sold.
They should check out tipc for message queueing. TIPC is a reliable messaging protocol designed for clusters. TIPC is fairly transparent whether a task is local or somewhere else on the network.
It's also why you'll never see a corporation admit guilt. By not admitting guilt, whenever they pay a fine they can deduct it from their taxes. Talk about corrupt.
Volcanic activity does not contribute much to greenhouse warming. The average annual output of CO2 from volcanic activity is far less than 1% what human activity emits. Volcanos also emit sulphur dioxide and ash which helps cool the planet by reflecting radiation back in to space.
On average, volcanos emit 200 million tons of CO2 per year. Human activity averages 26 BILLION tons per year.
This reminds me of my high school U.S. history class. I didn't make the honors class (I'm just as glad - the teacher was a fruit cake), but the regular class I was placed into was a complete joke. The book was written at a 5th grade level. There was almost no homework, and the tests were open book. One could easily get 100% on the test by just skimming the book, since the questions were in the order the material was in the text. The teacher was also the school football coach and sadly helped reinforce the stereotype of the dumb jock.
I complained to my counciler and quickly transferred to another history class. The other class was much more thorough and used college text books instead. I think it was quite a bit harder than the honors class. While many tests were also open book and he allowed 3x5 cards for notes, the class was far more difficult since you couldn't just skim for a name and a date.
The teacher graded on a strict curve, and while I did well, but many students did not because they didn't study or put in the required effort.
This is what classes should be. Perhaps they should also punish teachers who pass too many students, when some of those students obviously have no business in the class.
Sadly, after I graduated the state decided too much money was spent on administration and not enough on the classroom, so they eliminated many administration positions, including the student councilers (since they were not teachers). The councilers did a lot to help students, from working with them to get them the classes they wanted to helping them choose and get into various colleges.
Also remember that on the west coast there is very little coal energy production. Most power production is via natural gas and hydroelectric (with some wind and geothermal as well). Burning natural gas produces far less CO2 for a given amount of energy than say coal. If you look at the amount of CO2 emitted by a coal power plant, the amount is staggering. Coal is probably the worst fuel in terms of greenhouse gas emissions, or pollution in general.
Average annual CO2 emissions by all volcanos world-wide is 200 million tons. Human activity, by comparison, puts out on average 26 BILLION tons of CO2 per year. See here. Volcanos put out less than 1% of the CO2 as human activity.
I got my degree from the University of California at Santa Cruz before it was well known for engineering. They had a very good program and I had no problem getting a job after graduating. My ex roommate, on the other hand, went to a local California state college. As I helped him and saw the curriculum, I was surprised at how backwards it was compared to what I had to do. In many ways, even though I got my degree ten years ago, UCSC was far more advanced than Cal State Hayward. While many courses were the same, I thought CSH's courses were a joke compared to what I had to do. In many classes, my roommate had to hand in printouts of code or turn it in on floppy disks. Back in 1989 at UCSC, all of our code was submitted on the network and automated scripts performed the initial validation, i.e. compiling and running test data on it. We never handed in code printouts either, after all, that's what the network was for.
Helping my roommate with his homework further reinforced this view. Much of his homework for equivalent courses was much easier. Of course, when I took it we didn't have google or the other Internet resources available either.
While there may be a fair amount of He3 on the moon, extracting it is dangerous and very labour intensive. On the other hand, I have read that it would be far easier to collect He3 from Uranus atmosphere, even though the distance is significantly greater. Collection from Uranus could be totally automated too. Another source could be Saturn. See here.
I agree. It's about time that Linux provided a generic API for various drivers. Two types of drivers could exist, one type that sticks strictly with the API and the other that is not bound to it. For drivers that stick to the API they don't need to worry about being recompiled with each kernel version, only the API version. Different sets of APIs could be provided for different driver types. For example, network drivers have very different requirements than RAID drivers.
Most other operating systems do this and it's about time Linux provided some standards for drivers.
As much as we hate it, we do need to support binary only drivers.
It pisses me off that I can no longer use my webcam because the driver maintainer can't keep up with every variation of the kernel, and for legal reasons can't release the source code.
As someone who's worked with VxWorks for the last several years I'm surprised they didn't turn on priority inheritance to begin with for the semaphore. As a rule, we usually turn on priority inheritance for our mutex semaphores.
Other problems in the Mars Pathfinder were related to using the VxWorks filesystem. VxWorks basically only supports FAT on top of flash. For flash, FAT is a poor choice since some areas of the disk like the root directory and FAT tables will quickly wear out. Also, I don't think VxWorks has much support for working around bad sections of flash.
As far as VxWorks memory allocation support, in an ideal world one would statically allocate all memory, but oftentimes things are not ideal. In the product I work on, we have to have dynamic memory allocation, since depending on how the product is being used at the time, different data structures are required with no way of knowing beforehand how many of a particular type are needed, and this changes dynamically. For a simple device, it's easy to statically allocate everything, or if you have enough memory where you can statically allocate everything.
In our case, while we statically allocate memory where we can, however, in many cases we cannot. For example, I have to maintain a data structure keeping track of all of the network gateways connected to an output interface. We can have many thousands of gateways and thousands of output interfaces. There could be anything between one and thousands of gateways on an interface. In this case, I use static arrays for information on each gateway and each output interface, but must use dynamic data structures to list all the gateways connected to an output interface. It would be prohibitive to allocate storage for 30,000 gateways with 30,000 interfaces! I also can't use a linked list of gateways per interface since it doesn't scale, a linked list having access time O(n).
Also, we use third party libraries that perform dynamic memory allocation and it would be prohibitive to change that.
By replacing Wind River's malloc code with Doug Lea's code we eliminated fragmentation problems and saw our startup time jump from 50 minutes to 3 minutes. Doug Lea's malloc code is the basis of malloc in glibc and is very effecient. We also added support for tracing heap memory allocations to keep track of which task allocated a block and where it was allocated. This alone helped tremendously in tracking down a number of memory leaks since we can just walk the heap and see exactly where all the memory is being allocated. This is a sorely missing feature in VxWorks.
The lack of memory protection is another major problem for complex tasks. We have a bug we've spent weeks trying to track down the cause without any luck where random memory locations get corrupted.
Needless to say, all new projects where I work will not run on VxWorks. All of the chip vendors we're looking at are either dropping support for it or have already dropped it and are focusing on Linux.
BTW, this is one feature I would *REALLY* love to see added to Linux. The company I'm working for is looking at writing our next generation platform on top of an embedded Linux. We have not yet decided which one to use, but want something 2.6 based.
With priority inheritance, if a mutex is held by a low priority task and a high priority task tries to grab it, the low priority task is automatically boosted to the highest priority task that has attempted to acquire the semaphore. When the semaphore is released, the low priority task's priority is restored.
Some other nice features are interrupt scheduling and better priority based message passing support (which may already be present, I'm still looking into this).
Finally, one very useful feature would be the ability to guarantee a real-time thread a certain percentage of the CPU, with the option of placing a hard limit if it tries to exceed that or temporarily lowering it's priority to non-realtime so as to not starve no
Slashdot Mirror
It depends on the filter... I use numerous RBL databases in addition to blocking various countries (i.e. China, Russia, Nigeria, etc.). Just this step alone blocks most spam. In fact, it might be working too well since there's not enough left to effectively run the Bayes filters.
RBL filters consume very little in terms of CPU since it's all basically DNS lookups. It also prevents the spam payload from ever entering the mail server. There's other things I do with Postfix that turns my mail server into a tarpit for spammers. It also makes dictionary attacks of user names impossible while consuming very little bandwidth. Basically it holds onto the connection to the mail server and waits a predetermined amount of time before responding with an error code (i.e. 45 seconds). Note that some RBL filters are better than others, and some block legitimate sites.
Since I run my own mail server and don't know anyone in Russia or China, I can effectively block the entire countries (see blackhole.us).
Challenge response does not work well. In my case, there is a spammer out there who uses random email addresses at my domain name. Every time he sends a spam run I get anywhere from tens of thousands to over a hundred thousand bounced emails at my mail server. This server is for personal use only and is not designed to handle huge amounts of email, though Postfix doesn't seem to mind too much even though it's a 333MHz Pentium II box running Linux (uptime now at 595 days).
While my mail server doesn't seem to mind too much (other than huge log files), my Netgear firewall goes nuts from time to time forcing me to reboot it.
What would stop this type of DDOS I'm under? The gateway mail server should validate the recipient and return an error code right away instead of sending a bounced email later.
No Child Left Behind is a serious failure and is hurting some of our best schools. Here in the San Francisco Bay Area, some of the best schools in the nation, i.e. Cupertino, are being punished because the schools are being labeled as failing under the federal law. The law requires schools show continuous improvement, but as schools get better and better, this becomes more difficult to do. In the case of some of the school districts here in CA, it's due to too many students not taking the test. Apparently parents have the option of not letting their kids take the test, mostly for special ed. It's stupid to require some of these kids to take the tests. Some of the special ed. students are not much more than vegetables or cannot read due to mental disability.
Also, at least in the good schools around here it is often quite competitive and there is strong parent involvement. Part of it is that parents are willing to pay a premium when buying homes in the good school districts.
When I patched my SuSE X server with a Gentoo patch to use the new event mechanism I was pleasantly surprised to see that the tilt support worked in KDE applications. (it does not work in Firefox, BTW). Now I just wish the X protocol could be fixed to support more than 7 buttons, since I can only support the usual 3 buttons and vertical and horizontal scrolling. I wish I could assign other buttons as well on my Logitech MX1000.
Apparently there's experimental support for the PCTV HD-3000 card. This card supports NTSC, ATSC, and QAM. Unfortunately there's not much you can do with the encrypted signals. Apparently Comcast transmits all digital channels as encrypted except for the local stations. I have not personally tried the QAM support since it's currently a set of experimental patches against the latest driver code. -Aaron
Didn't SP2 make it impossible in Windows for an application to fill in an invalid source IP address? If this is the case, I wonder if this problem cropped up because Microsoft cannot generate the LAND attack with an up to date version of their OS.
Also, I wonder what sort of vulnerabilities exist in Windows for IPv6?
-Aaron
If you're setting the time every hour, it would probably be next to impossible to measure the drift since it will be so small and get lost in the normal packet jitter.
Also, at least some operating systems have the ability to detect drift from running NTP and can correct accordingly.
Back when I had an old Nokia cellphone for work (which I conveniently lost) I went through all the various ringtones it had trying to find the least obnoxious one. I finally found one that slowly increased to get your attention. The first ring was vibrate only, followed by a very short beep. The longer I waited the more insistant the ring became. I thought this was a good compromise. I think they should focus on finding the least annoying ringtones possible. But out of all the various ringtone combinations it had, it only had one clearly designed to be as unobtrusive as possible. This phone was before all the new polyphonic ringtones which now are so pervasive.
I rarely miss my cellphone since I misplaced it and let the battery run down over a year ago.
-Aaron
In terms of optimizing, generally compilers do a pretty good job, however there are several areas that no compiler I know of can help.
1. Choose the right algorithm. For example, in an embedded project I worked on an engineer used a linked list to store thousands of fields that must be added and deleted. While adding is fast, it didn't scale for deleting. Changed it to a hash table and it sped it up significantly.
2. Know your data and how it is used. Knowing how to organize your data and access it can make a huge difference. As a previous poster pointed out, sequential memory accesses are much faster than random accesses. I had to do some 90 degree image rotation code. The simple solution just used a couple for loops when copying the pixels from one buffer to another. In another, I took into account the processor cache and how memory is accessed and broke it down into tiles. The first algorithm, while simple and elegant ran at 30 frames per second. The other ran at over 200 frames per second. Looking at the code the first algorithm should be faster since the code is simpler. Both algorithms operate in O(N) time, where N=width * height.
Further optimization attempts to hint to the CPU cache about memory made no difference (Athlon XP 1700+). The only possible way I see to speed it up further would be to write it in hand-coded assembler.
3. Reduce the number of system calls if possible. Some operating systems can be very painful when calling the kernel. Group reads and writes together so fewer calls are made.
4. Profile your code to find bottlenecks.
5. Try and keep a tradeoff between memory usage and performance. A smaller tightly packed data set will execute faster with CPU caches and will reduce page faults when loading and starting up.
6. Try debugging your code at the assembler level, stepping through it. It will help you better understand your compiler.
7. Don't bother trying to optimize things like getting every ounce of performance when the next function you call will be very slow. I.e. in one section of MS DOS's source code which was hand-coded assembly language it was calculating the cluster or sector of the disk to access. First the code checked if it was running on a 16-bit or 32-bit CPU. Next it took the 16-bit or 32-bit path for multiplication, then it read from the disk. Why the hell write all this code to check the CPU if it's 16 or 32 bit for the multiply when the frigging disk is going to be slow. They should have just stuck with the 16-bit multiply rather than be clever.
In general applications with GCC, I rarely see much difference between -O2 or -O3. For that matter, I often don't see a noticable difference between -O0 and -O3 for a lot of code.
I only see improvements in some very CPU intensive multimedia code. I also saw a significant improvement in some multimedia code when I told the compiler to generate code for an Ultrasparc rather than the default, but that's because the pre-ultrasparc code didn't use a multiply instruction.
-Aaron
sed -e s/96768/48384/
Doh, put in the size for the quadraphonic version I tried to make with oggenc -C 4
(if multiple copies of this appear, I appologize... Slashdot keeps giving me Service Unavailable)
-Aaron
dd if=/dev/zero \ /tmp/OneMinuteThreeSecondsOfSilence
of=/tmp/OneMinuteThreeSecondsOfSilence \
bs=96768 count=1000
oggenc -r -R 192000 -q 10 \
-o OneMinuteThreeSecondsOfSilence.ogg \
Then share the file.
This created a 28977 byte ogg file of silence with a play time of 1 minute, 3 seconds. Note that this is a very high quality stereophonic file with a 192KHz sample rate and 16 bits per sample (oggenc doesn't seem to like more than 16 bits/sample or more than 2 channels).
Of course, I'm sure there's probably a way to do this in a single line, or you can skip the second step and just share the PCM file.
-Aaron
As someone who writes firmware that runs on a network processor, I can attest that the networking hardware is usually very different. For example, although the network processor runs at a lowly 133MHz it is able to forward 1.5 million packets/second when performing basic routing. I don't think there's any way a traditional processor could keep up. For one, the network processor has a massive amount of memory bandwidth and low latency, using SRAM for the tables. Other network processors use content addressable memory. To give an idea of memory bandwidth, one of the network processors I'm looking closely at has 11 separate memory interfaces to the chip, a mix of SRAM and DRAM.
Most of the work in the router is pattern matching, with a lot of lookups of various parts of the packet. The route lookup is actually one of the least expensive operations compared to all of the other operations that need to take place. Most of the high-end network processors have dedicated pattern matching hardware to speed up these operations and do not rely on caches which break when a lot of flows are active.
One operation we found to be very painful in a traditional processor is trying to shape traffic, i.e. using the Linux shaping options. Dedicated hardware, on the other hand, has no problems with this.
Now, I doubt many of these features would help much in a workstation or server. The only thing I can think of that would help significantly is some of the security operations, like being able to do offload encryption or do ACL lookups in hardware, much like how NVidia does this in their new NForce chipset. ACLs tend to be very expensive in terms of CPU cycles.
This story is a Dupe from yesterday.
One big advantage Sony has over Microsoft in the case of the PS3 is that Sony makes their own ASICs and can probably include them in the PS3 at cost. Microsoft has no such advantage. They must pay for the CPU and graphics chip which you can be sure will not be sold at a loss from the suppliers (i.e. ATI).
When you make your own ASICs, your cost for mass production are typically much lower than if you buy off the shelf parts, even if you pay someone else to make the parts for you.
By not making their own silicon, Microsoft is at a disadvantage, just like how now they must pay Intel and NVidia for every XBox 2 sold.
I hate to respond to my own post, but I forgot to include the link. TIPC is available under a dual license, both BSD and GPL. It can be found at http://tipc.so urceforge.net/</a>. We're planning on using it in an embedded project. It has good performance and reliability capabilities.
They should check out tipc for message queueing. TIPC is a reliable messaging protocol designed for clusters. TIPC is fairly transparent whether a task is local or somewhere else on the network.
-Aaron
It's also why you'll never see a corporation admit guilt. By not admitting guilt, whenever they pay a fine they can deduct it from their taxes. Talk about corrupt.
I just ran the test with Konqueror in SuSE Linux 9.2 based on KDE 3.3.0 and the problem does not exist.
On average, volcanos emit 200 million tons of CO2 per year. Human activity averages 26 BILLION tons per year.
See here, here or here, taken from an earlier Slashdot thread.
This reminds me of my high school U.S. history class. I didn't make the honors class (I'm just as glad - the teacher was a fruit cake), but the regular class I was placed into was a complete joke. The book was written at a 5th grade level. There was almost no homework, and the tests were open book. One could easily get 100% on the test by just skimming the book, since the questions were in the order the material was in the text. The teacher was also the school football coach and sadly helped reinforce the stereotype of the dumb jock.
I complained to my counciler and quickly transferred to another history class. The other class was much more thorough and used college text books instead. I think it was quite a bit harder than the honors class. While many tests were also open book and he allowed 3x5 cards for notes, the class was far more difficult since you couldn't just skim for a name and a date.
The teacher graded on a strict curve, and while I did well, but many students did not because they didn't study or put in the required effort.
This is what classes should be. Perhaps they should also punish teachers who pass too many students, when some of those students obviously have no business in the class.
Sadly, after I graduated the state decided too much money was spent on administration and not enough on the classroom, so they eliminated many administration positions, including the student councilers (since they were not teachers). The councilers did a lot to help students, from working with them to get them the classes they wanted to helping them choose and get into various colleges.
Also remember that on the west coast there is very little coal energy production. Most power production is via natural gas and hydroelectric (with some wind and geothermal as well). Burning natural gas produces far less CO2 for a given amount of energy than say coal. If you look at the amount of CO2 emitted by a coal power plant, the amount is staggering. Coal is probably the worst fuel in terms of greenhouse gas emissions, or pollution in general.
Average annual CO2 emissions by all volcanos world-wide is 200 million tons. Human activity, by comparison, puts out on average 26 BILLION tons of CO2 per year. See here. Volcanos put out less than 1% of the CO2 as human activity.
I got my degree from the University of California at Santa Cruz before it was well known for engineering. They had a very good program and I had no problem getting a job after graduating. My ex roommate, on the other hand, went to a local California state college. As I helped him and saw the curriculum, I was surprised at how backwards it was compared to what I had to do. In many ways, even though I got my degree ten years ago, UCSC was far more advanced than Cal State Hayward. While many courses were the same, I thought CSH's courses were a joke compared to what I had to do. In many classes, my roommate had to hand in printouts of code or turn it in on floppy disks. Back in 1989 at UCSC, all of our code was submitted on the network and automated scripts performed the initial validation, i.e. compiling and running test data on it. We never handed in code printouts either, after all, that's what the network was for.
Helping my roommate with his homework further reinforced this view. Much of his homework for equivalent courses was much easier. Of course, when I took it we didn't have google or the other Internet resources available either.
Not all colleges are created equal.
-Aaron
While there may be a fair amount of He3 on the moon, extracting it is dangerous and very labour intensive. On the other hand, I have read that it would be far easier to collect He3 from Uranus atmosphere, even though the distance is significantly greater. Collection from Uranus could be totally automated too. Another source could be Saturn. See here.
I agree. It's about time that Linux provided a generic API for various drivers. Two types of drivers could exist, one type that sticks strictly with the API and the other that is not bound to it. For drivers that stick to the API they don't need to worry about being recompiled with each kernel version, only the API version. Different sets of APIs could be provided for different driver types. For example, network drivers have very different requirements than RAID drivers.
Most other operating systems do this and it's about time Linux provided some standards for drivers.
As much as we hate it, we do need to support binary only drivers.
It pisses me off that I can no longer use my webcam because the driver maintainer can't keep up with every variation of the kernel, and for legal reasons can't release the source code.
-Aaron
As someone who's worked with VxWorks for the last several years I'm surprised they didn't turn on priority inheritance to begin with for the semaphore. As a rule, we usually turn on priority inheritance for our mutex semaphores.
Other problems in the Mars Pathfinder were related to using the VxWorks filesystem. VxWorks basically only supports FAT on top of flash. For flash, FAT is a poor choice since some areas of the disk like the root directory and FAT tables will quickly wear out. Also, I don't think VxWorks has much support for working around bad sections of flash.
As far as VxWorks memory allocation support, in an ideal world one would statically allocate all memory, but oftentimes things are not ideal. In the product I work on, we have to have dynamic memory allocation, since depending on how the product is being used at the time, different data structures are required with no way of knowing beforehand how many of a particular type are needed, and this changes dynamically. For a simple device, it's easy to statically allocate everything, or if you have enough memory where you can statically allocate everything.
In our case, while we statically allocate memory where we can, however, in many cases we cannot. For example, I have to maintain a data structure keeping track of all of the network gateways connected to an output interface. We can have many thousands of gateways and thousands of output interfaces. There could be anything between one and thousands of gateways on an interface. In this case, I use static arrays for information on each gateway and each output interface, but must use dynamic data structures to list all the gateways connected to an output interface. It would be prohibitive to allocate storage for 30,000 gateways with 30,000 interfaces! I also can't use a linked list of gateways per interface since it doesn't scale, a linked list having access time O(n).
Also, we use third party libraries that perform dynamic memory allocation and it would be prohibitive to change that.
By replacing Wind River's malloc code with Doug Lea's code we eliminated fragmentation problems and saw our startup time jump from 50 minutes to 3 minutes. Doug Lea's malloc code is the basis of malloc in glibc and is very effecient. We also added support for tracing heap memory allocations to keep track of which task allocated a block and where it was allocated. This alone helped tremendously in tracking down a number of memory leaks since we can just walk the heap and see exactly where all the memory is being allocated. This is a sorely missing feature in VxWorks.
The lack of memory protection is another major problem for complex tasks. We have a bug we've spent weeks trying to track down the cause without any luck where random memory locations get corrupted.
Needless to say, all new projects where I work will not run on VxWorks. All of the chip vendors we're looking at are either dropping support for it or have already dropped it and are focusing on Linux.
BTW, this is one feature I would *REALLY* love to see added to Linux. The company I'm working for is looking at writing our next generation platform on top of an embedded Linux. We have not yet decided which one to use, but want something 2.6 based.
With priority inheritance, if a mutex is held by a low priority task and a high priority task tries to grab it, the low priority task is automatically boosted to the highest priority task that has attempted to acquire the semaphore. When the semaphore is released, the low priority task's priority is restored.
Some other nice features are interrupt scheduling and better priority based message passing support (which may already be present, I'm still looking into this).
Finally, one very useful feature would be the ability to guarantee a real-time thread a certain percentage of the CPU, with the option of placing a hard limit if it tries to exceed that or temporarily lowering it's priority to non-realtime so as to not starve no