The question is, how realistic is it that anyone can really get anything useful doing this?
Set up a repeater unit outside of an executive's house, then do trades on the stock market. You could hide all the electronics in a small box, and make it look like a piece of phone or telco equipment. No one would touch it for 20 years.
The harder activity would be to disguise the trades so the SEC doesn't figure it out.
I bet someone has already tried something like this. There are too many security agencies in the world for it not to have been tried at least once...
So, we plunk down my yearly salary for the product and a support contract and low-and-behold not only doesn't the site work, it actually displays an error message... Basically, that proprietary software simply makes my life harder.
Often the more expensive the piece of software is, the worse the software is. It is a perverse example of applied economics. Expensive software sells in small volumes, so the vendors try to maximize profit per customer. Effectively, this means minimizing effort in software development, resulting in crappy software.
Companies selling large volumes of software, find technical support costs a large cost center. This forces the companies to increase software quality and increase ease of use, even if only to reduce technical support costs. However, to achieve the volumes of sales, these same companies often reduce the unit price of the software. High-volume software vendors are trying to maximize the formula: revenue = unit cost * # of sales. Thus most high-volume titles cost much less than the more expensive low-volume titles, and are also better quality pieces of software.
Open source takes things to an extreme. The software is free, the source is free, so the number of users is large. The number of bug fixes will also be large, if the number of developers scales with the number of users. Of course, the number of developers on an open-source project is a function of both revenue and the number of bugs, and with open source projects, revenue is a key issue. Nevertheless, some open source projects have identified revenue streams, and are good quality projects.
The end result is expensive software is usually crappy, and cheaper software is often better.
Give up - The performance hit is inevitable
on
Zombie Network Explosion
·
· Score: 4, Interesting
Speaking as someone that regularly works on number processing and real-time applications, I've given up on Windows machines. I just assume every Windows box is running ample code that is outside my control, and that code will make the machine much slower for any mathematically intensive computations, especially if they involve disk access or network access. All of the anti-virus code designed to stop viruses and bot-nets is killing Windows as a platform.
One way or another, you pay your speed and uptime penalty. You either pay in downtime caused by the "bad" guys writing bot-nets, malware or viruses, or you pay in slow speed caused by the "good" guys like Microsoft, Symantec, and McAfee, who are trying to stop the bot-nets, malware and viruses. The modern "good" vs. "bad" arms race is resulting in anti-virus software that is so slow that it is strangling the Windows platform with endless code bloat. If you want to prove this to yourself, get an older PC with a fresh Windows installation. Start installing software on it, one package at a time. As the newer service packs are applied, the anti-virus software installed, and the software packages installed, the PC will actually slow down!
Building better anti-virus software for Windows is self-defeating. It slows the computer down to the point that Windows is useless.
I think I have seen that feature in a fairly popular accounting / cash register package here in Canada too. The program can support up to 4 different cash boxes. Now I know what that feature was for...
The problem with Mad Cow disease is that it is extremely rare. If you slaughter 35 million cows annually, and only 1 in 10,000,000 cows have the disease, then a 1% testing regime is essentially guaranteed to never find the problem. With the numbers given, the 1% testing regime has only a 3.4% chance of detecting a 1 in 10,000,000 problem. Worse, some sample bias is likely present in the 1%, because it will be weighted disproportionately on the younger cattle, as meat cattle are often slaughtered young and young cattle are less likely to have mad cow disease. On the other hand, a 100% testing regime will almost certainly detect mad cow disease, as everything will be tested. Of course, if you find the problem, then it will be a big issue for the meat industry, which will then have to do something about it. This type of strategy is what made the problem so massive in Britain before it was finally caught and dealt with.
From everything I have read, there almost certainly was trace quantities of mad cow disease in the North American meat supply, and these trace quantities will be undetectable with current sampling methods. As such, we cannot really be certain that mad cow is definitely not present anymore, because we are not testing the meat supply effectively enough to find out.
You are forgetting that in an old COBOL system like this, hundreds of other modifications have already been made using the "decorator pattern". It becomes difficult to figure out which lines of code, and possibly even which tables in the database are in active use. Changing everyones salary in the salary table may have no effect, because someone may already be using the "decorator pattern" to automatically generate the salary table. There may be so many rules and exceptions, that no one clearly understands them all.
Writing a short program to make a wholesale change only works if the underlying system is simple enough that the consequences of the wholesale change can be accurately predicted. When you are dealing with payroll, you have to get it right. You don't want to suddenly start paying obscure part-time staff full-time hours. Even at minimum wage, you still have to pay overtime. This all must be done in reference to the appropriate union contracts, precedents, and the relevant tax and labor laws. These are complex laws.
You might even need a team of tax and labor lawyers to figure out the tax and labor law ramifications of your wage changes, so the wage change comes into effect in a legal and proper manner. In the end, this just isn't simple.
They probably are not planning to build the computer exactly the same way it was done in the 1980's. They are probably planning to copy just a few stylistic items.
For instance, a modern micro-controller CPU would integrate almost the entire Apple II motherboard onto one chip, including the RAM, ROM, and peripherals. You can use the cheap hack (like the Apple II did) to generate composite video signals from just a few TTL output pins. If you pick the right microcontroller, DMA can be used to automatically output the video bitstream, and a built in counter timer can be used to generate the video clock. Additionally, most microcontrollers have I/O pins designed for keyboard scanning built into them. The result is one chip and a few miscellaneous components accomplishes everything on the motherboard of the original Apple II.
Unfortunately, you will still need a case, power supply, and keyboard. The keyboard could be the most expensive part of the design.
The rough approach of creating a bootable computer from a microcontroller is in widespread use. When I start a new micro-controller design, I frequently program a small boot monitor into the early versions of the CPU. This allows me to download new programs and manually test the on-board peripherals. Communication is done via RS-232 to a local PC. Occasionally, the same approach is used in Windows and Linux when doing kernel debugging from a remote PC. There is nothing to stop someone from programming a microcontroller in a higher level language like BASIC. Parallax has built a product around it, namely the BASIC Stamp. In practice, if you already have an in-circuit programmable microcontroller attached to a PC, then it is often easier to program on the PC and transfer a compiled C program as opposed to hacking with BASIC and assembly. However, this varies from application to application, with what the designers preferences are, and how old-school and hard-core of a hardware hacker that you are dealing with.
Could it be that FutureMark uses the GenuineIntel and AMD flags to enable processor specific extensions? and then does a whole bunch of math with those extensions and never bothers to check the result?
This would indicate some really terrible code on FutureMarks part, and VIA should be flagging those op-codes as illegal op-codes, but it might be possible that something like this could happen. It is even possible that the CPUID checks are duplicated in some library somewhere that actually gets the correct code sequence right, and the main FutureMark code disables the advanced functions of the library whenever the GenuineIntel and AMD flags are missing. Thus FutureMark may feature both code sequences that work and those that don't, and the resulting incompatibilities are what causes the issues.
At the risk of replying to my own question, if you are running DNSMasq on your router, you can use the command:
bogus-nxdomain=64.94.110.11
To block any given IP address, and thus override Rogers override. This works to prevent Rogers from displaying its search page, no matter what URL you enter.
Assuming you are running a Linux or OpenBSD based router, would it be possible to modify the configuration of the router so any attempt to reach search.rogers.com results in a NXDOMAIN record being returned? This could be a nifty mod to DD-WRT and similar packages.
I know this isn't the "right" fix, but it might be very effective.
I think the reason this suit got this far, and generated as much interesting legal materials and reactions as it did, have much to do with the lawyer working the case. She would have not got this far, if it was not for the efforts of her lawyer. You have demonstrated how to defend and win a case against the RIAA.
It is not often that we think of lawyers as the good guys, but in this case, the community owes you thanks.
The consensus among human factors professionals is that a light gray background is best
For one control systems application, we researched the ideal background color. After much studious analysis, we finally decided on a slightly brownish light gray color. The idea was that on a wide variety of monitors in use at the plant, the color would always display as either light gray or a slightly brownish light gray.
The reasoning was essentially the same as what you describe. Every other color displays well against gray.
It is however poor practice to depend only on color. For the systems I work on, I aim to distinguish warning based on Color, Shape (or Text), and Size (or Boldness.) Many people in plants suffer from one form of impairment or another, and it is really bad to rely on a single distinguishing feature to attract an operator's attention.
The old color schemes were well researched. When people were paying $100,000's on their mainframes, they wanted monitors that worked well for their operators. The productivity of the mainframe depended on it. This resulted in many of the old monitors being amber on black or green on black rather than the easier to build white on black monitors.
For color monitors, the white on blue and yellow on blue schemes are the best. Black on white isn't bad; it has the virtue of being high contrast. White on black is still one of the worst color schemes. I never got a good explanation of why black on white is good (think original Apple Mac), vs. white on black is bad (original IBM CGA).
Resolution and refresh rate are also important. Generally, rendering the same number of characters at a higher resolution is easier on the eyes. Thus, the original IBM PC Hercules monochrome card is a much nicer screen to program on than the original IBM PC CGA video card. It wasn't until VGA that the color resolution on the IBM PC was as good as the monochrome resolution, and people started switching in a broad way to color only displays.
Finally, look at purchasing a pair of glasses. Even if you have "borderline" vision, like I do, they may ease eye fatigue. At first, they will probably bother you, until you get used to using them.
This needs an RFC
on
Real Snail Mail
·
· Score: 2, Interesting
Good software means lacking in bugs, maintainable, modifiable, scalable, etc.
The only way you get software with few bugs that is easy to maintain is if you are developing simple software against known requirements. Unfortunately, almost all the interesting commercial software has unknown software requirements.
In embedded systems, which often have simple programs, the enemy is unforeseen conditions. What happens to this system in actual use? If the system is always doing the same thing, then the software may have lots of "software engineering" bugs, but in practice has a very low bug count. Alternatively, the inputs could be relatively unknown, things could be constantly changing, and lots of practical problems (bugs) will happen. Bottom line: the real world makes it impossible to predict the environment that embedded software will execute in. This causes lots of problems for an embedded application.
Leaving the embedded world, you have programs that interact with people. Getting accurate requirements information on them is next to impossible. How are you supposed to write a "bug-free, maintainable, modifiable, and scalable program" when you don't actually know what the program is supposed to do? Many people related applications involve user-interface design, requirements analysis and business processes. Software engineers gradually learn about the intended application through a process of iterative improvement. The constant iterations cause the complexities in software that drive bugs, make code difficult to maintain, create endless modifications, and add scalability as a last minute requirement.
About the only category of program that is easy to get bug-free is something that is designed to interact with another program, or a program that takes very defined inputs and has very defined outputs. Compilers are often in this category. Even with compilers, there are complexities. Theoretically, you can formally prove a complier correct. In practice, I am just not sure that once software programs become large (like gcc), that it can be proven correct and optimal Formal methods can get stuck on rather complex proofs. For instance, given an idealized computer, one might hope to prove a C compiler generates code as intended. However, this would be an idealized compiler generating code for an idealized computer architecture.
In the real world, the IA-32 computer architecture is a mess. Intel doesn't even know how all possible instruction sequences should execute. To help solve the problem, Intel created a software model of their own microprocessor, and this model became the Intel internal standard. Intel has not released this model to the general public. Further, if Intel did release it, the formal methods people would likely find obscure bug cases that also exist in silicon. Thus even something obvious like proving a compiler generates correct code, becomes a very difficult when one realizes that the real-world lacks proper mathematical definitions.
Real-life contains much grey. The greyness drives the software problems.
Microsoft sees a movement away from Win32 before too long, and even current applciations a lot of developers are working on projects that stretch from generic Win32 to fully hybrind Win32/WPF/DirectX all in one application.
I think you nailed a comment on Microsoft's API strategies there. Microsoft keeps adding API's, but they don't actually replace one another. In the case of a long-running project, you wind up with hybrid fraken-apps. This makes Windows application development rather horrible, and I suspect gives Windows operating system developers nightmares. As a person that likes emulators, I look at the Microsoft API, I look at Wine, and think: Why would anyone implement that API?
The simplest way to launch satellites is to design a great big gun. The U.S. did some experiments with this with Project HARP. They were abandoned because manned flight required lower g-forces. However, if you just wanted to put a satellite into orbit, then guns can make sense.
Unfortunately, the last guy to try this (Gerald V. Bull), went on to attempt to build a super-gun for Saddam Hussein, and then mysteriously got shot (possibly by Israel's Mossad).
I'm not sure I want to win this contest. There have been quite a few projects in the area, and they all get canceled.
My understanding was the conformal coating doesn't stop whiskers from forming. Small whiskers can simply grow straight through the coating. Besides, most conformal coating processes are designed to keep hands or screwdrivers or loose wires from shorting the circuit board by touching it. It isn't obvious to me that the conformal coating gets between pins and underneath pins in such a manner that would stop all possible whiskers from shorting to all possible nasty locations. Can conformal coating even get underneath the leads of an LQFP package (with 100% coverage)? A BGA package?
Conformal coatings may mitigate risk, but I don't think they are a "solution". Also, the performance of conformal coatings probably varies widely with type and quality of the coating and quality of application. Conformal coatings are in the category of "any manufacturer that cares enough to get the conformal coating correct, probably also knows enough to get the tin-replacement solder chemistry correct and avoid the problem in the first place."
I think we have to worry about the cheap subcomponents from relatively unknown factories being assembled into larger subsystems that are in turn assembled into larger machines/products/cars/etc. To have a quality problem, we only need one whisker on one circuit board, and there are lots of circuit boards in most machines (and most other devices too.) The "not checking the suppliers" problem is what caused the leaky electrolytic capacitor problem. It only took a few inexpensive capacitors to cause lots of computer problems.
I am a person that designs both hardware, and software, but not chips, At the risk of talking outside of my expertise, I will have a go at answering your question.
Firstly, there are things that software people really like, but it is often better to not do them in hardware. This category contains things like Read/Write I/O registers. From a software point of view, they are nice, but they can double your gate count. They can also increase your capacitive bus loading. DAC and ADC designs can also be affected this way. A software person might use a proper ADC and expect proper ADC registered results. A hardware person might select a resistor, capacitor, a voltage comparitor, and a couple of spare I/O pins. The cheesy R/C approach may save the hardware design from a whole slew of problems including cost. A software person may opt for a synchronous logic approach with all registers clocked every clock cycle. The hardware designer may opt for a much more asynchronous approach, that minimizes the number of clocked registers. This reduces power consumption, and potentially the number of registers too. Often the hardware designer will consider thermal, cost, electrical layout issues as part of his design process. The software person will not be as familiar with how to design a good circuit board and chip design in a cost-effective manner. A good software engineer can learn all of this material with time, but the hardware engineers will do them naturally.
The second category of problems is tools. The modern chip designer is working with a fairly advanced set of tools that the software person is likely to be quite unfamiliar with. This starts with the IC design tools, which are quite specialized. It ends with the hardware engineering tools. Have you ever X-Rayed a circuit board to analyze the cracks in the Ball Grid Array where it bonds to the circuit board? Are you familiar with thermal issues, and thermal images? How about EMI test results? Modern IC package design limitations? A good team of engineers will be familiar with these tools, and know how to use them to get good results.
The third category of problems is mistakes from inexperience, or lack of experience in the correct field. I work with industrial electronics. I think from an industrial point of view. What happens when someone attaches 600 (VAC) to the ground wire of the computer? What happens to the remote sensors when the plant gets hit by lightening? In IC design, there are some known gray areas too. Does the chip reset properly on power up? Do metastable, astable, or self-oscillating states exist in the IC design? Can the chip survive with no cooling? Does the chip have an overtemp shutdown function? What happens if someone starts the chip up in sub-zero weather? Do the analog electronics have sufficient electrical separation from the digital electronics, while avoiding nasty things like ESD latchup conditions?
I've completed chip design courses before, but have never had to design a modern production gate array design. As a person that has done both software and hardware, I know that my skills are not good enough for the most modern IC design processes. My limit is FPGA work, and my preference is clever opto-isolation, power semiconductor, TTL and micro-proccessor based circuits. In analog, my expertise in analog is industrial sensing and survivability. You have to know where your field of expertise is, and what your limits are.
A heavier car will de-accelerate less and so reduce the g force on the driver, try rolling a 1lb ball into a 2lb ball and see which one goes backwards.
The older large cars and almost all trucks, vans, and SUVs often have much poorer crumple zone designs than modern passenger cars. Passenger cars are built to tougher standards than SUVs. The g-force experienced by an occupant of an SUV can frequently exceed the g-force experienced by an occupant of a car, particularly if both are driven into a fixed obstacle.
Your ball analogy is confusing momentum with forces seen by the passenger during impact. The more rigid the balls are, the effectively momentum will be transferred. The goal in a car accident, is to absorb the momentum in the body of the car. You don't want the rapid change in momentum to be absorbed by the passenger or the passenger compartment. In car accident terms, when the 1lb ball hits the 2lb ball, you want both to stop. How quickly each comes to rest is governed how each absorbs the impact. If the 1lb ball is a car, then the crumple zone is designed to absorb the impact. This reduces impact felt by the occupants. If the 2lb ball is something really stiff, like a big block of steel, then the entire force for the impact is transmitted directly to the occupant. This is really bad.
Incidentally, this is why the newer SUVs and pickups have crumple zones, and crush up like the small cars do now. You want the vehicle to take the impact, not the occupant. Nevertheless, SUVs are often made to truck standards, not passenger car standards, and frequently passenger cars have many more passenger protecting features.
Does anyone remember the good old days when Metal Gate CMOS represented a power efficient process? We have went from CMOS devices consuming milliwatts and microwatts to processors with a 125W+ Total Power Dissipation. This announcement is talking about 180 Watts per layer!
How long will it be before my computer heats my house while I browse the internet? When does the first combined datacenter and heating cogeneration system get installed?
The most protocol efficient way to handle this is to use an MD5 checksum and JavaScript to detect tampering with the web page. If the web page is changed, then redirect the user automatically to an https server. That way, the https protocol is only used for users suffering from web-page tampering.
A more evil application of the Level 7 interception technology would be to intercept he GIF and JPG images of the advertisements themselves, and replace just the images. This would be more difficult to detect from JavaScript. Effectively, all the advertisements would need to be encrypted too. The big problem with encrypting images, is that it would make the progressive download and page display algorithms used by web browsers useless. It would also defeat any proxy and website caching software used by the ISPs.
Deploying Level 7 interception may lead to a market response that could ultimately increase the bandwidth costs of ISPs. It could force every internet communication to be a encrypted secure communication, defeating all in-transit caching algorithms.
I noticed that quote too. It is completely despicable that they would remove charity advertisements. Actually, I think the entire system boils down to theft and unlawful interception of traffic.
What if the phone company inserted commercial adds when you were talking to someone on the phone?
Slashdot Mirror
Set up a repeater unit outside of an executive's house, then do trades on the stock market. You could hide all the electronics in a small box, and make it look like a piece of phone or telco equipment. No one would touch it for 20 years.
The harder activity would be to disguise the trades so the SEC doesn't figure it out.
I bet someone has already tried something like this. There are too many security agencies in the world for it not to have been tried at least once ...
Newsflash: This was IBM's effort to patent thinking about patents. They just patented a method of finding new areas that don't have patents.
Often the more expensive the piece of software is, the worse the software is. It is a perverse example of applied economics. Expensive software sells in small volumes, so the vendors try to maximize profit per customer. Effectively, this means minimizing effort in software development, resulting in crappy software.
Companies selling large volumes of software, find technical support costs a large cost center. This forces the companies to increase software quality and increase ease of use, even if only to reduce technical support costs. However, to achieve the volumes of sales, these same companies often reduce the unit price of the software. High-volume software vendors are trying to maximize the formula: revenue = unit cost * # of sales. Thus most high-volume titles cost much less than the more expensive low-volume titles, and are also better quality pieces of software.
Open source takes things to an extreme. The software is free, the source is free, so the number of users is large. The number of bug fixes will also be large, if the number of developers scales with the number of users. Of course, the number of developers on an open-source project is a function of both revenue and the number of bugs, and with open source projects, revenue is a key issue. Nevertheless, some open source projects have identified revenue streams, and are good quality projects.
The end result is expensive software is usually crappy, and cheaper software is often better.
Speaking as someone that regularly works on number processing and real-time applications, I've given up on Windows machines. I just assume every Windows box is running ample code that is outside my control, and that code will make the machine much slower for any mathematically intensive computations, especially if they involve disk access or network access. All of the anti-virus code designed to stop viruses and bot-nets is killing Windows as a platform.
One way or another, you pay your speed and uptime penalty. You either pay in downtime caused by the "bad" guys writing bot-nets, malware or viruses, or you pay in slow speed caused by the "good" guys like Microsoft, Symantec, and McAfee, who are trying to stop the bot-nets, malware and viruses. The modern "good" vs. "bad" arms race is resulting in anti-virus software that is so slow that it is strangling the Windows platform with endless code bloat. If you want to prove this to yourself, get an older PC with a fresh Windows installation. Start installing software on it, one package at a time. As the newer service packs are applied, the anti-virus software installed, and the software packages installed, the PC will actually slow down!
Building better anti-virus software for Windows is self-defeating. It slows the computer down to the point that Windows is useless.
Run Linux. Take control of your own computer.
I think I have seen that feature in a fairly popular accounting / cash register package here in Canada too. The program can support up to 4 different cash boxes. Now I know what that feature was for ...
The problem with Mad Cow disease is that it is extremely rare. If you slaughter 35 million cows annually, and only 1 in 10,000,000 cows have the disease, then a 1% testing regime is essentially guaranteed to never find the problem. With the numbers given, the 1% testing regime has only a 3.4% chance of detecting a 1 in 10,000,000 problem. Worse, some sample bias is likely present in the 1%, because it will be weighted disproportionately on the younger cattle, as meat cattle are often slaughtered young and young cattle are less likely to have mad cow disease. On the other hand, a 100% testing regime will almost certainly detect mad cow disease, as everything will be tested. Of course, if you find the problem, then it will be a big issue for the meat industry, which will then have to do something about it. This type of strategy is what made the problem so massive in Britain before it was finally caught and dealt with.
From everything I have read, there almost certainly was trace quantities of mad cow disease in the North American meat supply, and these trace quantities will be undetectable with current sampling methods. As such, we cannot really be certain that mad cow is definitely not present anymore, because we are not testing the meat supply effectively enough to find out.
The correct word is women . Women is the plural of woman, just as men is the plural of man.
You are forgetting that in an old COBOL system like this, hundreds of other modifications have already been made using the "decorator pattern". It becomes difficult to figure out which lines of code, and possibly even which tables in the database are in active use. Changing everyones salary in the salary table may have no effect, because someone may already be using the "decorator pattern" to automatically generate the salary table. There may be so many rules and exceptions, that no one clearly understands them all.
Writing a short program to make a wholesale change only works if the underlying system is simple enough that the consequences of the wholesale change can be accurately predicted. When you are dealing with payroll, you have to get it right. You don't want to suddenly start paying obscure part-time staff full-time hours. Even at minimum wage, you still have to pay overtime. This all must be done in reference to the appropriate union contracts, precedents, and the relevant tax and labor laws. These are complex laws.
You might even need a team of tax and labor lawyers to figure out the tax and labor law ramifications of your wage changes, so the wage change comes into effect in a legal and proper manner. In the end, this just isn't simple.
They probably are not planning to build the computer exactly the same way it was done in the 1980's. They are probably planning to copy just a few stylistic items.
For instance, a modern micro-controller CPU would integrate almost the entire Apple II motherboard onto one chip, including the RAM, ROM, and peripherals. You can use the cheap hack (like the Apple II did) to generate composite video signals from just a few TTL output pins. If you pick the right microcontroller, DMA can be used to automatically output the video bitstream, and a built in counter timer can be used to generate the video clock. Additionally, most microcontrollers have I/O pins designed for keyboard scanning built into them. The result is one chip and a few miscellaneous components accomplishes everything on the motherboard of the original Apple II.
Unfortunately, you will still need a case, power supply, and keyboard. The keyboard could be the most expensive part of the design.
The rough approach of creating a bootable computer from a microcontroller is in widespread use. When I start a new micro-controller design, I frequently program a small boot monitor into the early versions of the CPU. This allows me to download new programs and manually test the on-board peripherals. Communication is done via RS-232 to a local PC. Occasionally, the same approach is used in Windows and Linux when doing kernel debugging from a remote PC. There is nothing to stop someone from programming a microcontroller in a higher level language like BASIC. Parallax has built a product around it, namely the BASIC Stamp. In practice, if you already have an in-circuit programmable microcontroller attached to a PC, then it is often easier to program on the PC and transfer a compiled C program as opposed to hacking with BASIC and assembly. However, this varies from application to application, with what the designers preferences are, and how old-school and hard-core of a hardware hacker that you are dealing with.
Could it be that FutureMark uses the GenuineIntel and AMD flags to enable processor specific extensions? and then does a whole bunch of math with those extensions and never bothers to check the result?
This would indicate some really terrible code on FutureMarks part, and VIA should be flagging those op-codes as illegal op-codes, but it might be possible that something like this could happen. It is even possible that the CPUID checks are duplicated in some library somewhere that actually gets the correct code sequence right, and the main FutureMark code disables the advanced functions of the library whenever the GenuineIntel and AMD flags are missing. Thus FutureMark may feature both code sequences that work and those that don't, and the resulting incompatibilities are what causes the issues.
At the risk of replying to my own question, if you are running DNSMasq on your router, you can use the command:
To block any given IP address, and thus override Rogers override. This works to prevent Rogers from displaying its search page, no matter what URL you enter.
Assuming you are running a Linux or OpenBSD based router, would it be possible to modify the configuration of the router so any attempt to reach search.rogers.com results in a NXDOMAIN record being returned? This could be a nifty mod to DD-WRT and similar packages.
I know this isn't the "right" fix, but it might be very effective.
I think the reason this suit got this far, and generated as much interesting legal materials and reactions as it did, have much to do with the lawyer working the case. She would have not got this far, if it was not for the efforts of her lawyer. You have demonstrated how to defend and win a case against the RIAA.
It is not often that we think of lawyers as the good guys, but in this case, the community owes you thanks.
Good Work.
For one control systems application, we researched the ideal background color. After much studious analysis, we finally decided on a slightly brownish light gray color. The idea was that on a wide variety of monitors in use at the plant, the color would always display as either light gray or a slightly brownish light gray.
The reasoning was essentially the same as what you describe. Every other color displays well against gray.
It is however poor practice to depend only on color. For the systems I work on, I aim to distinguish warning based on Color, Shape (or Text), and Size (or Boldness.) Many people in plants suffer from one form of impairment or another, and it is really bad to rely on a single distinguishing feature to attract an operator's attention.
The old color schemes were well researched. When people were paying $100,000's on their mainframes, they wanted monitors that worked well for their operators. The productivity of the mainframe depended on it. This resulted in many of the old monitors being amber on black or green on black rather than the easier to build white on black monitors.
For color monitors, the white on blue and yellow on blue schemes are the best. Black on white isn't bad; it has the virtue of being high contrast. White on black is still one of the worst color schemes. I never got a good explanation of why black on white is good (think original Apple Mac), vs. white on black is bad (original IBM CGA).
Resolution and refresh rate are also important. Generally, rendering the same number of characters at a higher resolution is easier on the eyes. Thus, the original IBM PC Hercules monochrome card is a much nicer screen to program on than the original IBM PC CGA video card. It wasn't until VGA that the color resolution on the IBM PC was as good as the monochrome resolution, and people started switching in a broad way to color only displays.
Finally, look at purchasing a pair of glasses. Even if you have "borderline" vision, like I do, they may ease eye fatigue. At first, they will probably bother you, until you get used to using them.
I can see it coming already: TCP/IP over snails. A follow up to RFC-1149 A Standard for the Transmission of IP Datagrams on Avian Carriers.
The only way you get software with few bugs that is easy to maintain is if you are developing simple software against known requirements. Unfortunately, almost all the interesting commercial software has unknown software requirements.
In embedded systems, which often have simple programs, the enemy is unforeseen conditions. What happens to this system in actual use? If the system is always doing the same thing, then the software may have lots of "software engineering" bugs, but in practice has a very low bug count. Alternatively, the inputs could be relatively unknown, things could be constantly changing, and lots of practical problems (bugs) will happen. Bottom line: the real world makes it impossible to predict the environment that embedded software will execute in. This causes lots of problems for an embedded application.
Leaving the embedded world, you have programs that interact with people. Getting accurate requirements information on them is next to impossible. How are you supposed to write a "bug-free, maintainable, modifiable, and scalable program" when you don't actually know what the program is supposed to do? Many people related applications involve user-interface design, requirements analysis and business processes. Software engineers gradually learn about the intended application through a process of iterative improvement. The constant iterations cause the complexities in software that drive bugs, make code difficult to maintain, create endless modifications, and add scalability as a last minute requirement.
About the only category of program that is easy to get bug-free is something that is designed to interact with another program, or a program that takes very defined inputs and has very defined outputs. Compilers are often in this category. Even with compilers, there are complexities. Theoretically, you can formally prove a complier correct. In practice, I am just not sure that once software programs become large (like gcc), that it can be proven correct and optimal Formal methods can get stuck on rather complex proofs. For instance, given an idealized computer, one might hope to prove a C compiler generates code as intended. However, this would be an idealized compiler generating code for an idealized computer architecture.
In the real world, the IA-32 computer architecture is a mess. Intel doesn't even know how all possible instruction sequences should execute. To help solve the problem, Intel created a software model of their own microprocessor, and this model became the Intel internal standard. Intel has not released this model to the general public. Further, if Intel did release it, the formal methods people would likely find obscure bug cases that also exist in silicon. Thus even something obvious like proving a compiler generates correct code, becomes a very difficult when one realizes that the real-world lacks proper mathematical definitions.
Real-life contains much grey. The greyness drives the software problems.
I think you nailed a comment on Microsoft's API strategies there. Microsoft keeps adding API's, but they don't actually replace one another. In the case of a long-running project, you wind up with hybrid fraken-apps. This makes Windows application development rather horrible, and I suspect gives Windows operating system developers nightmares. As a person that likes emulators, I look at the Microsoft API, I look at Wine, and think: Why would anyone implement that API?
The simplest way to launch satellites is to design a great big gun. The U.S. did some experiments with this with Project HARP. They were abandoned because manned flight required lower g-forces. However, if you just wanted to put a satellite into orbit, then guns can make sense.
Unfortunately, the last guy to try this (Gerald V. Bull), went on to attempt to build a super-gun for Saddam Hussein, and then mysteriously got shot (possibly by Israel's Mossad).
I'm not sure I want to win this contest. There have been quite a few projects in the area, and they all get canceled.
My understanding was the conformal coating doesn't stop whiskers from forming. Small whiskers can simply grow straight through the coating. Besides, most conformal coating processes are designed to keep hands or screwdrivers or loose wires from shorting the circuit board by touching it. It isn't obvious to me that the conformal coating gets between pins and underneath pins in such a manner that would stop all possible whiskers from shorting to all possible nasty locations. Can conformal coating even get underneath the leads of an LQFP package (with 100% coverage)? A BGA package?
Conformal coatings may mitigate risk, but I don't think they are a "solution". Also, the performance of conformal coatings probably varies widely with type and quality of the coating and quality of application. Conformal coatings are in the category of "any manufacturer that cares enough to get the conformal coating correct, probably also knows enough to get the tin-replacement solder chemistry correct and avoid the problem in the first place."
I think we have to worry about the cheap subcomponents from relatively unknown factories being assembled into larger subsystems that are in turn assembled into larger machines/products/cars/etc. To have a quality problem, we only need one whisker on one circuit board, and there are lots of circuit boards in most machines (and most other devices too.) The "not checking the suppliers" problem is what caused the leaky electrolytic capacitor problem. It only took a few inexpensive capacitors to cause lots of computer problems.
I am a person that designs both hardware, and software, but not chips, At the risk of talking outside of my expertise, I will have a go at answering your question.
Firstly, there are things that software people really like, but it is often better to not do them in hardware. This category contains things like Read/Write I/O registers. From a software point of view, they are nice, but they can double your gate count. They can also increase your capacitive bus loading. DAC and ADC designs can also be affected this way. A software person might use a proper ADC and expect proper ADC registered results. A hardware person might select a resistor, capacitor, a voltage comparitor, and a couple of spare I/O pins. The cheesy R/C approach may save the hardware design from a whole slew of problems including cost. A software person may opt for a synchronous logic approach with all registers clocked every clock cycle. The hardware designer may opt for a much more asynchronous approach, that minimizes the number of clocked registers. This reduces power consumption, and potentially the number of registers too. Often the hardware designer will consider thermal, cost, electrical layout issues as part of his design process. The software person will not be as familiar with how to design a good circuit board and chip design in a cost-effective manner. A good software engineer can learn all of this material with time, but the hardware engineers will do them naturally.
The second category of problems is tools. The modern chip designer is working with a fairly advanced set of tools that the software person is likely to be quite unfamiliar with. This starts with the IC design tools, which are quite specialized. It ends with the hardware engineering tools. Have you ever X-Rayed a circuit board to analyze the cracks in the Ball Grid Array where it bonds to the circuit board? Are you familiar with thermal issues, and thermal images? How about EMI test results? Modern IC package design limitations? A good team of engineers will be familiar with these tools, and know how to use them to get good results.
The third category of problems is mistakes from inexperience, or lack of experience in the correct field. I work with industrial electronics. I think from an industrial point of view. What happens when someone attaches 600 (VAC) to the ground wire of the computer? What happens to the remote sensors when the plant gets hit by lightening? In IC design, there are some known gray areas too. Does the chip reset properly on power up? Do metastable, astable, or self-oscillating states exist in the IC design? Can the chip survive with no cooling? Does the chip have an overtemp shutdown function? What happens if someone starts the chip up in sub-zero weather? Do the analog electronics have sufficient electrical separation from the digital electronics, while avoiding nasty things like ESD latchup conditions?
I've completed chip design courses before, but have never had to design a modern production gate array design. As a person that has done both software and hardware, I know that my skills are not good enough for the most modern IC design processes. My limit is FPGA work, and my preference is clever opto-isolation, power semiconductor, TTL and micro-proccessor based circuits. In analog, my expertise in analog is industrial sensing and survivability. You have to know where your field of expertise is, and what your limits are.
The older large cars and almost all trucks, vans, and SUVs often have much poorer crumple zone designs than modern passenger cars. Passenger cars are built to tougher standards than SUVs. The g-force experienced by an occupant of an SUV can frequently exceed the g-force experienced by an occupant of a car, particularly if both are driven into a fixed obstacle.
Your ball analogy is confusing momentum with forces seen by the passenger during impact. The more rigid the balls are, the effectively momentum will be transferred. The goal in a car accident, is to absorb the momentum in the body of the car. You don't want the rapid change in momentum to be absorbed by the passenger or the passenger compartment. In car accident terms, when the 1lb ball hits the 2lb ball, you want both to stop. How quickly each comes to rest is governed how each absorbs the impact. If the 1lb ball is a car, then the crumple zone is designed to absorb the impact. This reduces impact felt by the occupants. If the 2lb ball is something really stiff, like a big block of steel, then the entire force for the impact is transmitted directly to the occupant. This is really bad.
Incidentally, this is why the newer SUVs and pickups have crumple zones, and crush up like the small cars do now. You want the vehicle to take the impact, not the occupant. Nevertheless, SUVs are often made to truck standards, not passenger car standards, and frequently passenger cars have many more passenger protecting features.
Does anyone remember the good old days when Metal Gate CMOS represented a power efficient process? We have went from CMOS devices consuming milliwatts and microwatts to processors with a 125W+ Total Power Dissipation. This announcement is talking about 180 Watts per layer!
How long will it be before my computer heats my house while I browse the internet? When does the first combined datacenter and heating cogeneration system get installed?
The most protocol efficient way to handle this is to use an MD5 checksum and JavaScript to detect tampering with the web page. If the web page is changed, then redirect the user automatically to an https server. That way, the https protocol is only used for users suffering from web-page tampering.
A more evil application of the Level 7 interception technology would be to intercept he GIF and JPG images of the advertisements themselves, and replace just the images. This would be more difficult to detect from JavaScript. Effectively, all the advertisements would need to be encrypted too. The big problem with encrypting images, is that it would make the progressive download and page display algorithms used by web browsers useless. It would also defeat any proxy and website caching software used by the ISPs.
Deploying Level 7 interception may lead to a market response that could ultimately increase the bandwidth costs of ISPs. It could force every internet communication to be a encrypted secure communication, defeating all in-transit caching algorithms.
I noticed that quote too. It is completely despicable that they would remove charity advertisements. Actually, I think the entire system boils down to theft and unlawful interception of traffic.
What if the phone company inserted commercial adds when you were talking to someone on the phone?