Part of that was because computers in the early days were mostly used for number crunching—financial calculations, computing launch trajectories for missiles, etc. With the advent of home computing, that changed, because suddenly 99% of the things that people do with computers don't involve nontrivial amounts of math. It isn't that the math became less important in areas where it was important before, but rather that other, non-math-centric areas of computing grew at orders of magnitude faster rates.
You must not be developing anything significantly complex.
No, I write a lot of relatively complex code. It just doesn't involve very much math. The most recent time that I wrote code with any significant amount of math involved a Diffie-Hellman key exchange. In that work, I wasn't doing the large number math; the software was. And at a conceptual level, raising numbers to a power still falls within the "no higher than 7th grade math" area, IIRC, regardless of how many digits the values happen to be (which is what makes it impractical to do by hand).
I had to write a Reed-Solomon encoder/decoder recently.
When most people need error correction code, they grab an off-the-shelf library that someone wrote once, and use it. Same goes for crypto, Fourier transforms, and most of the other complex math stuff. That's why very, very few programmers (percentage-wise) ever write code that uses high-level math directly—not because they don't end up using it indirectly, but because the indirection layers to do the work already exist, and unless you have very specific needs (like optimizing performance on a particular embedded platform), there's little point in reinventing the wheel.
Mind you, if you want to work for NASA or various scientific research firms, yes, you'll probably need a solid grasp of high-level math. And there are some jobs where a good understanding of statistics comes in handy as well. But those jobs make up just a small percentage of the programming jobs out there, so you can do very well in programming and make a good living at it without knowing calculus, statistics, or combinatorics.
Yeah, if you're not going beyond basic code monkey work (desktop apps, database CRUD, etc), then you're probably not going to need anything beyond 7th grade algebra.
Desktop apps that talk to hardware aren't basic code monkey work, yet they rarely do any appreciable amount of math. Compilers and parsers can be highly complex, but they rarely use any math at all (apart from boolean logic). Even OS kernels use nontrivial amounts of math in only a few spots (like the scheduler), and that math is still mostly limited to addition, subtraction, multiplication, and division. Most people would not call driver writing, kernel programming or compiler writing "basic code monkey work". Just saying.:-)
No, we need less passionate coders. All the passionate developers I've seen (older and younger than me) don't have time for [boring] stuff like unit tests, documentation, following specs, learning "old stuff", etc...
Only because tech managers and teachers have failed to properly impress upon young engineers the importance of doing that stuff.
I'm a pretty passionate coder. I find unit tests to be downright tedious, and if I'm doing something as a favor for someone and not getting paid to do it, you can safely expect zero tests, because it works now, and it is somebody else's problem if you break it later. Similarly, if I'm doing something that mostly involves UI, you can expect few to zero tests because it isn't practical to write them.
With that said, if I'm writing code that involves serious data processing, I always include tests (even if the tests are sometimes limited to black-box testing of relatively large functional units).
As for documentation, the last software project I was really passionate about whose code was complex enough to warrant much documentation had comments in over 36% of the lines of code. That's not to say that there were comments on a third of the lines of actual code, mind you—much of that involved large comment blocks at the start of classes that documented all the interesting member variables, explained how the class worked, etc. at a high level—but I took pride in ensuring that if I ever left the company (which I did) that any idiot could pick up the code, stare at it for a while, and quickly be able to fix bugs in an almost 20,000 LoC state machine spread across five or six classes.
More to the point, other people besides me have actually successfully written patches for that monstrosity, so apparently the documentation is at least somewhat successful at getting people past their initial terror reaction and into a mode in which the code starts to make sense.
Why do I do these things? Because I learned how valuable comments are from having to deal with other people's terrible code over the years. IMO, reading other people's code should be a required part of every CS curriculum. If you can't make changes in some random kernel driver, you probably shouldn't be writing software for public consumption, and by the time you achieve that ability, you will fully understand why such "boring" tasks like documentation are important.:-)
4. To the inquirer. Answers such as "Math is hard" or "the guys are bullies" are NOT objective truths, but personal perceptions and, as such, need to be further reinforced by actual concrete instances. And, in fact, if there is the perception that "math is hard" or "the guys are bullies" without objective proff, then additional research needs to be made. Locate the source of these perceptions, address any actual problems found, work to correct any mis-conceptions.
The perception about math is kind of irrelevant, IMO. In two decades of programming, I can count the number of times I've used math above the seventh grade level on one hand, in unary. Yes, there's CS work that involves math, but most of the people doing that work are scientists who also know how to write code, rather than coders who also know complex math. So if that's someone's excuse for not getting into computer programming, the misconceptions run much deeper than whether math is hard....
What programming does require is a high degree of abstract thinking. Folks who do well in algebra are likely to have no trouble with programming. Mind you, there's a big difference between solving for a variable and assigning a value to one, but at its core, the notion of a name that represents a value is still the same. And that abstract thinking ability becomes critical when you're architecting a piece of software, imagining how the parts are going to fit together before any of them exist. The better you are at thinking abstractly, the better you'll do at programming, from the lowest code monkey jobs to the highest software architect jobs.
Unfortunately, at least in the United States, IIRC, most tests show a gap in abstract thinking ability between men and women by the time they reach high school. Whether that gap is biological or social in nature is unclear, but as long as that gap in the mean/median of abstract thinking ability exists, you'd expect more men in computer programming than women, because a larger percentage of men will find it easy to learn the core programming concepts, and to then move on to complex architecture work. To achieve a more balanced tech workforce, you have two choices: either take steps to encourage women with strong abstract thinking abilities to choose CS at a higher rate than men with those abilities (a higher percentage of a smaller population) or fix that abstract thinking gap (assuming that it isn't caused by biological differences). All other problems (e.g. "men are jerks") are secondary in importance by comparison to the abstract thinking gap, IMO.
Because out of all of those professions, programming is the only one that is an insular profession (in the "isolated" sense of the word). Mechanics and plumbers interact with women all the time. So do garbage men, carpenters, and to some degree, miners. Programmers spend their lives behind a screen and are lucky to even see women in an average month. Anything we can do to improve the gender balance results in a higher rate of little geeks, which improves the average intelligence of the species.
With turbo boost, it runs until it hits a thermal limit, then scales the clock speed back a bit at a time until the load stops or it hits a speed at which it can run continuously without overheating. So it almost certainly will eventually throttle back to a lower clock speed, but that may or may not be 1.4 GHz. For example, if you are running only one core at full throttle, it will probably not scale back that far.
But no, it almost certainly cannot run at 2.7 GHz 24x7.
They coat the chips in some sort of coating that insulates them.
My first inclination would be to get the biggest heat sink I could find, fasten it to the motherboard, and build a 12V to 5V and 3.3V DC-DC converter (and 1.8V, if needed). By not starting from 110VAC, you can cut the PSU heat to a level that might be manageable without fans. Then get extension cables for any connectors that you want to keep usable, along with a couple of heavy gauge wires for your 12V leads, stick the whole thing in a plastic box or bag with the cables hanging out the top, and fill it with epoxy....
Mind you, such an approach is almost certainly not advisable, but that would be my first inclination.:-D
As many folks have already pointed out in other threads on the subject, Intel screwed up the Haswell line by using an entirely different pinout on the i7 than on the i5. The result is that any motherboard with soldered-on chips has to be specifically designed for one or the other.
Apple chose the i5, presumably because that's the hardware grade where most of the Mini's sales came from, rather than doubling their R&D cost by building two very different motherboards.
Here's hoping Intel doesn't screw up Broadwell in the same way.
They only fix 2 problems - weak passwords and keyloggers.
That's not true. They also provide protection against:
Shoulder surfing attacks, which require no compromise to the internals of the endpoint
Storage of data encrypted with a protocol that later proves vulnerable in some interesting way, such as a key compromise
For example, consider heartbleed. If someone stores your encrypted communication, and later compromises a host's private key, that attacker could ostensibly decrypt those communications. If you use a password, that password is compromised, and it's "Game over, man." If you use a physical token, only the PIN is compromised (assuming the actual verification happens in a separate process).
Ideally, you would still want to issue new PIN codes, but the account hijacking risk would be largely mitigated by the physical token requirement, at least after the n-hour cookie expiration window passes, and you could even eliminate that window by expiring any cookies in your authentication database before bringing it back online after you fix the heartbleed vulnerability.
Regardless of the fact that it may be legal for others to do so, it's unethical and clearly misrepresentation.
Not true. Lots of small homebrew hardware uses off-the-shelf chips like the ones FTDI builds without applying for their own VID/PID combo. This causes minor headaches because software can't tell them apart from one another, but as long as the final product doesn't have a USB logo on it, it is perfectly acceptable to sell it, even if your homebrew flash programmer looks like a USB to serial adapter to any software that asks.
If you want to use the USB logo, you have to apply for your own VID/PID combo and reprogram the chip to identify itself as being your product, and ship a custom driver that talks to it (which could be a modified version of the official FTDI driver, or the open source driver, or whatever).
As other people have pointed out, not all of the fake chips have those markings—or any markings, for that matter. This tells me that some company special-ordered batches of chips that were silk screened with those markings, but that the part normally comes blank.
First, there's no such thing as "illegal access to software". The customer may be violating a licensing agreement, but as a rule, that's not a criminal offense.
Second, I'm pretty sure there are third-party FTDI drivers out there. So you really can't make the argument that the clone chip vendors don't have an alternate driver. The best you can do is state that if a clone gets bricked, it means that the commercial FTDI driver was loaded at least once by the customer for some reason (possibly with the intent to use it with the clone hardware, but possibly to use it with some other device), and that it matched the clone because it was attached while that driver was loaded.
Actually, if you sell it as a "USB/Serial converter", then you are, because the USB mark is trademarked.
Only if they use the USB trident mark. The letters "USB" are likely to be held as descriptive.
If some medical device manufacturer uses a consumer-grade FTDI chip - counterfeit or not - in a medical appliance, then that manufacturer is the one who would be liable, as FTDI has already made it clear that these chips are not certified for such uses.
Liability is not binary. If the failure were accidental, you'd be correct. Because it is deliberate, at best, both companies would be held liable—the medical device vendor for choosing an unsuitable part and FTDI for deliberately breaking it, and at worst, FTDI would be held solely liable for deliberately breaking it.
No, I haven't solved any of the hard problems, because determining whether a colored ball or arrow is meaningful really isn't one of them. The hard problems are things like:
recognizing and handling road signs
dealing with potentially contradictory lane markings
dealing with rain on the cameras
determining which way to swerve when avoiding obstacles (like a dog running across the road), and whether to brake instead, or do both
choosing whether it is better to hit the object in the road or swerve into the next lane (including computing the distance and speed of an oncoming vehicle correctly, even if it is a motorcycle)
handling four-way stops when other vehicles don't follow the rules
determining weather conditions sufficiently to compute braking distance correctly (Is it rainy or just cloudy?)
recognizing that there are kids playing by the side of the road and you should probably slow down just in case one of them falls out into the street....
Traffic lights are relatively straightforward by comparison, so long as they are working.
Describe for me, programmatically, the difference between a stoplight and a taillight.
That's easy. The stoplight is above you. Two cameras at different angle provide sufficient parallax to tell the difference between something far away on a hill and something nearby above the car. And you're done.
and a police light
Same answer.
and a neon sign
Same answer, plus the stoplight is not on the side of the road, as computed based on distance to the edge of the road when looking forward.
and also, please include all the many shapes and sizes of the various stoplights all over the country.
No need. Humans can't see the shape of the fixture when driving at night, but that limitation has never been a problem. You just need to know the color and to be able to figure out which colored light corresponds with which lane.
its video cameras can sometimes be blinded by the sun when trying to detect the color of a traffic signal.
So can people. One possible solution would be radio signals in every traffic light to indicate the light's state. No signal and can't see the light? Stop the car and tell the driver to take over. This would be useful for eliminating confusion when you have multiple lights as well, so it might be worth pursuing.
That said, the simpler fix is to use a higher quality camera with better lens coatings. I can't remember the last time I saw lens flare that blew out a picture to the point that it was truly unusable except when using old camera gear with uncoated lenses. For additional robustness, put more than one camera on the front, pointed in different directions. That way, lens flare should never be a problem, in practice. (Lens flare tends to be angle-specific, and the sun is in one spot, so if a lens at one angle is in a position to flare badly, a second lens at a different angle probably won't be, assuming your lenses aren't old, uncoated nightmares.)
it can't tell the difference between a big rock and a crumbled-up piece of newspaper
Neither can people, reliably, unless it is blowing. Whatever you see in the road, it is best to avoid it.:-)
Slashdot Mirror
"Just because you're paranoid doesn't mean they aren't after you."
—Joseph Heller
Yes, they should stay home and gaze at warships.
Yeah, I've herd of bison. Why do you ask?
Part of that was because computers in the early days were mostly used for number crunching—financial calculations, computing launch trajectories for missiles, etc. With the advent of home computing, that changed, because suddenly 99% of the things that people do with computers don't involve nontrivial amounts of math. It isn't that the math became less important in areas where it was important before, but rather that other, non-math-centric areas of computing grew at orders of magnitude faster rates.
No, I write a lot of relatively complex code. It just doesn't involve very much math. The most recent time that I wrote code with any significant amount of math involved a Diffie-Hellman key exchange. In that work, I wasn't doing the large number math; the software was. And at a conceptual level, raising numbers to a power still falls within the "no higher than 7th grade math" area, IIRC, regardless of how many digits the values happen to be (which is what makes it impractical to do by hand).
When most people need error correction code, they grab an off-the-shelf library that someone wrote once, and use it. Same goes for crypto, Fourier transforms, and most of the other complex math stuff. That's why very, very few programmers (percentage-wise) ever write code that uses high-level math directly—not because they don't end up using it indirectly, but because the indirection layers to do the work already exist, and unless you have very specific needs (like optimizing performance on a particular embedded platform), there's little point in reinventing the wheel.
Mind you, if you want to work for NASA or various scientific research firms, yes, you'll probably need a solid grasp of high-level math. And there are some jobs where a good understanding of statistics comes in handy as well. But those jobs make up just a small percentage of the programming jobs out there, so you can do very well in programming and make a good living at it without knowing calculus, statistics, or combinatorics.
Desktop apps that talk to hardware aren't basic code monkey work, yet they rarely do any appreciable amount of math. Compilers and parsers can be highly complex, but they rarely use any math at all (apart from boolean logic). Even OS kernels use nontrivial amounts of math in only a few spots (like the scheduler), and that math is still mostly limited to addition, subtraction, multiplication, and division. Most people would not call driver writing, kernel programming or compiler writing "basic code monkey work". Just saying. :-)
Only because tech managers and teachers have failed to properly impress upon young engineers the importance of doing that stuff.
I'm a pretty passionate coder. I find unit tests to be downright tedious, and if I'm doing something as a favor for someone and not getting paid to do it, you can safely expect zero tests, because it works now, and it is somebody else's problem if you break it later. Similarly, if I'm doing something that mostly involves UI, you can expect few to zero tests because it isn't practical to write them.
With that said, if I'm writing code that involves serious data processing, I always include tests (even if the tests are sometimes limited to black-box testing of relatively large functional units).
As for documentation, the last software project I was really passionate about whose code was complex enough to warrant much documentation had comments in over 36% of the lines of code. That's not to say that there were comments on a third of the lines of actual code, mind you—much of that involved large comment blocks at the start of classes that documented all the interesting member variables, explained how the class worked, etc. at a high level—but I took pride in ensuring that if I ever left the company (which I did) that any idiot could pick up the code, stare at it for a while, and quickly be able to fix bugs in an almost 20,000 LoC state machine spread across five or six classes.
More to the point, other people besides me have actually successfully written patches for that monstrosity, so apparently the documentation is at least somewhat successful at getting people past their initial terror reaction and into a mode in which the code starts to make sense.
Why do I do these things? Because I learned how valuable comments are from having to deal with other people's terrible code over the years. IMO, reading other people's code should be a required part of every CS curriculum. If you can't make changes in some random kernel driver, you probably shouldn't be writing software for public consumption, and by the time you achieve that ability, you will fully understand why such "boring" tasks like documentation are important. :-)
Then again, I could just be grumpy.
The perception about math is kind of irrelevant, IMO. In two decades of programming, I can count the number of times I've used math above the seventh grade level on one hand, in unary. Yes, there's CS work that involves math, but most of the people doing that work are scientists who also know how to write code, rather than coders who also know complex math. So if that's someone's excuse for not getting into computer programming, the misconceptions run much deeper than whether math is hard....
What programming does require is a high degree of abstract thinking. Folks who do well in algebra are likely to have no trouble with programming. Mind you, there's a big difference between solving for a variable and assigning a value to one, but at its core, the notion of a name that represents a value is still the same. And that abstract thinking ability becomes critical when you're architecting a piece of software, imagining how the parts are going to fit together before any of them exist. The better you are at thinking abstractly, the better you'll do at programming, from the lowest code monkey jobs to the highest software architect jobs.
Unfortunately, at least in the United States, IIRC, most tests show a gap in abstract thinking ability between men and women by the time they reach high school. Whether that gap is biological or social in nature is unclear, but as long as that gap in the mean/median of abstract thinking ability exists, you'd expect more men in computer programming than women, because a larger percentage of men will find it easy to learn the core programming concepts, and to then move on to complex architecture work. To achieve a more balanced tech workforce, you have two choices: either take steps to encourage women with strong abstract thinking abilities to choose CS at a higher rate than men with those abilities (a higher percentage of a smaller population) or fix that abstract thinking gap (assuming that it isn't caused by biological differences). All other problems (e.g. "men are jerks") are secondary in importance by comparison to the abstract thinking gap, IMO.
Because out of all of those professions, programming is the only one that is an insular profession (in the "isolated" sense of the word). Mechanics and plumbers interact with women all the time. So do garbage men, carpenters, and to some degree, miners. Programmers spend their lives behind a screen and are lucky to even see women in an average month. Anything we can do to improve the gender balance results in a higher rate of little geeks, which improves the average intelligence of the species.
With turbo boost, it runs until it hits a thermal limit, then scales the clock speed back a bit at a time until the load stops or it hits a speed at which it can run continuously without overheating. So it almost certainly will eventually throttle back to a lower clock speed, but that may or may not be 1.4 GHz. For example, if you are running only one core at full throttle, it will probably not scale back that far.
But no, it almost certainly cannot run at 2.7 GHz 24x7.
It's simple enough to implement in a shell script. At least three or four of us have done it over the years.
My first inclination would be to get the biggest heat sink I could find, fasten it to the motherboard, and build a 12V to 5V and 3.3V DC-DC converter (and 1.8V, if needed). By not starting from 110VAC, you can cut the PSU heat to a level that might be manageable without fans. Then get extension cables for any connectors that you want to keep usable, along with a couple of heavy gauge wires for your 12V leads, stick the whole thing in a plastic box or bag with the cables hanging out the top, and fill it with epoxy....
Mind you, such an approach is almost certainly not advisable, but that would be my first inclination. :-D
Even that isn't a "No True Scotsman" fallacy, because there was no initial flawed assertion, nor a counterexample that disproves that assertion.
As many folks have already pointed out in other threads on the subject, Intel screwed up the Haswell line by using an entirely different pinout on the i7 than on the i5. The result is that any motherboard with soldered-on chips has to be specifically designed for one or the other.
Apple chose the i5, presumably because that's the hardware grade where most of the Mini's sales came from, rather than doubling their R&D cost by building two very different motherboards.
Here's hoping Intel doesn't screw up Broadwell in the same way.
That's not true. They also provide protection against:
For example, consider heartbleed. If someone stores your encrypted communication, and later compromises a host's private key, that attacker could ostensibly decrypt those communications. If you use a password, that password is compromised, and it's "Game over, man." If you use a physical token, only the PIN is compromised (assuming the actual verification happens in a separate process).
Ideally, you would still want to issue new PIN codes, but the account hijacking risk would be largely mitigated by the physical token requirement, at least after the n-hour cookie expiration window passes, and you could even eliminate that window by expiring any cookies in your authentication database before bringing it back online after you fix the heartbleed vulnerability.
So you're saying they made a new network for blackjack and hookers? You know what, forget the network. And the hookers.
Not true. Lots of small homebrew hardware uses off-the-shelf chips like the ones FTDI builds without applying for their own VID/PID combo. This causes minor headaches because software can't tell them apart from one another, but as long as the final product doesn't have a USB logo on it, it is perfectly acceptable to sell it, even if your homebrew flash programmer looks like a USB to serial adapter to any software that asks.
If you want to use the USB logo, you have to apply for your own VID/PID combo and reprogram the chip to identify itself as being your product, and ship a custom driver that talks to it (which could be a modified version of the official FTDI driver, or the open source driver, or whatever).
As other people have pointed out, not all of the fake chips have those markings—or any markings, for that matter. This tells me that some company special-ordered batches of chips that were silk screened with those markings, but that the part normally comes blank.
And who would want a 9" pianist figurine anyway?
First, there's no such thing as "illegal access to software". The customer may be violating a licensing agreement, but as a rule, that's not a criminal offense.
Second, I'm pretty sure there are third-party FTDI drivers out there. So you really can't make the argument that the clone chip vendors don't have an alternate driver. The best you can do is state that if a clone gets bricked, it means that the commercial FTDI driver was loaded at least once by the customer for some reason (possibly with the intent to use it with the clone hardware, but possibly to use it with some other device), and that it matched the clone because it was attached while that driver was loaded.
Besides, they aren't FTDI's chips, so FTDI's statement about what uses their chips are certified for is irrelevant.
Only if they use the USB trident mark. The letters "USB" are likely to be held as descriptive.
Liability is not binary. If the failure were accidental, you'd be correct. Because it is deliberate, at best, both companies would be held liable—the medical device vendor for choosing an unsuitable part and FTDI for deliberately breaking it, and at worst, FTDI would be held solely liable for deliberately breaking it.
No, I haven't solved any of the hard problems, because determining whether a colored ball or arrow is meaningful really isn't one of them. The hard problems are things like:
Traffic lights are relatively straightforward by comparison, so long as they are working.
No, that's the next generation, when they add backscatter and/or millimeter-wave scanners.
That's easy. The stoplight is above you. Two cameras at different angle provide sufficient parallax to tell the difference between something far away on a hill and something nearby above the car. And you're done.
Same answer.
Same answer, plus the stoplight is not on the side of the road, as computed based on distance to the edge of the road when looking forward.
No need. Humans can't see the shape of the fixture when driving at night, but that limitation has never been a problem. You just need to know the color and to be able to figure out which colored light corresponds with which lane.
So can people. One possible solution would be radio signals in every traffic light to indicate the light's state. No signal and can't see the light? Stop the car and tell the driver to take over. This would be useful for eliminating confusion when you have multiple lights as well, so it might be worth pursuing.
That said, the simpler fix is to use a higher quality camera with better lens coatings. I can't remember the last time I saw lens flare that blew out a picture to the point that it was truly unusable except when using old camera gear with uncoated lenses. For additional robustness, put more than one camera on the front, pointed in different directions. That way, lens flare should never be a problem, in practice. (Lens flare tends to be angle-specific, and the sun is in one spot, so if a lens at one angle is in a position to flare badly, a second lens at a different angle probably won't be, assuming your lenses aren't old, uncoated nightmares.)
Neither can people, reliably, unless it is blowing. Whatever you see in the road, it is best to avoid it. :-)