I have a theory about why rms is so insistent that Linux be called "GNU/Linux" and it has nothing to do with the explanation he gives, which I find completely nonpersuasive. Please, don't assume that I disagree with their reasoning because I don't understand it and, therefore, explain it to me in an attempt to convince me. I understand the logic, I merely disagree with it.
Anyway, in the mid-1990's there was a joke going around. I first heard it from my friend the FreeBSD fan. The joke?
Q: What's the difference between GNU and Linux?
A: Linux has a kernel that boots.
At about the time that joke came out, the FSF engaged in a major effort to get the GNU/HURD to boot. After many months of work, you could kind of get it to run, but it was in no way useful. Shortly after, rms started insisting that people call Linux GNU/Linux.
It sure looks like the major effort was a response to that joke and, when that effort failed, they decided to respond to the punchline "Linux has a kernel that boots" with "no, Linux IS a kernel that boots." I presume they thought that devastating. To me, it seemed pathetic. I mean, with all of their resources and more than a decade of work, they weren't able to do what Linus Torvalds did all by himself in a few weeks. I think that it's an excellent example of how hard "big bang" development is when compared to a more incremental style.
100Km is about 328,000 feet. That's why Space Ship One had a tail number of N328KF.
Also, the North Texas Balloon Team and the South Texas Balloon Project routinely (with launches approximately annually) send balloons with video cameras to altitudes in excess of 100,000 feet. Those are just the two balloon projects I'm familiar with. I am sure there are others because it's not particularly hard to do.
So, this is pure ho-hum to me. Let me know when they've done it a couple of dozen times.
I could never do anything in Railroad Tycoon II except run out of money, but I was just running Civilization: Call to Power last night on my 64-bit Debian box last night, so what's all this noise about nothing working?
Actually, it's not that hard, at least if you're running Apache. You simply set up one server to receive all the incoming requests and then use Apache's proxy capability to forward the request to the server it should actually go to. My home network is like that. Actually, my home network also runs IPv6 and the IPv6 address resolves to the actual destination computer, but IPv6 connectivity being what it is (that is, nearly nonexistent) I needed to figure out how to make it work with the single IPv4 address I had.
The Windows memory manager knows far more than you do...
That reminds me of the oven in my house that apparently knows far more than I do about whether or not I want to bake anything. My intention is to replace it as soon as the repairs to fix the damage from hurricane Ike are complete, and I'm going to replace it with the dumbest appliance I can find.
Look, I know the logic that that says that since RAM is a scarce resource a virtual memory manager must be running at all times to properly manage that scarce resource. I read about it the last time it came up on Slashdot, and, well, I didn't believe it then, either. Oh, I believe the assertion that a scarce resource must be carefully managed. It's just that I no longer believe that semiconductor RAM is particularly scarce. I mean, if I could demonstrate that all of my programs' working sets and all of the file data that they're going to access can all fit in RAM at once, then wouldn't you agree that virtual memory management is unnecessary?
Of course, demonstrating that everything is going to fit in semiconductor RAM is not a trivial task, but I can't help but think that caching a lot of most large files is pretty useless. I mean, if you're streaming a video of a movie, you need to prefetch enough of it that you don't have to worry about underruns and once you've played a frame there's no point in keeping it around any longer, so I would think that 100 MB of buffer would suffice for videos that are gigabytes long and 100 MB is 2.5% of the memory in a computer that has 4G of semiconductor RAM. That implies that the bulk of the benefit of caching comes from caching small files, like the intermediate files generated when compiling or processing email or stuff like that.
Of course, my not believing something doesn't make it false, but I'd still like to see some more effort placed into demonstrating that semiconductor RAM remains a scarce resource. I'm afraid that your bittorrent seeding example suggests to me rather the opposite: RAM on your machine is so plentiful that you have to seed a hundred Linux ISOs to make it scarce.
I'm glad it works well for you. Still, I can't help but wonder what you would find if you gathered statistics about those errors found by inspection as opposed to those errors that inspection failed to find and had to be found some other way. Would you determine that the effort is worth the time? I wonder.
As it happens, last Friday I had occasion to do review some code. You see, I had discovered that something was causing an error in my client-facing API code and by reviewing the thrust of all of the changes in Subversion, I concluded that the error had to be in a particular function and the code that had been last changed in that function was not too long, only a dozen lines or so. The code was written by someone who is perhaps the best programmer in the place, and it was properly formatted and in the same style as the rest of the code. However, I knew that the change in question was badly broken as I was reviewing the code and I couldn't see the error.
It was only as I dug deeper than a review could cover, and took advantage of the additional information from my knowledge of the symptoms to conclude that a particular branch that should have been taken was not, in fact, being taken, which lead me to realize that a particular variable was not being properly initialized in a loop. That code should have been moved out of the loop when the code was reorganized and simplified, but it had not been, which resulted in the error.
In addition to the timing, I find this defect interesting for two reasons. First, because an inspection would have utterly failed to detect that the change was broken. I mean, I looked right at the code and couldn't see it despite being familiar with the context and such and armed with the knowledge that it contained an error. Second, this sort of flubbing up a reorganization is a common error when writing prose.
The whole "clearly defined requirements" thing is a straw man, as you well know. I have found that specifications are always subject to change and so you need a methodology that can deal with that. The thing is, I have not found that the popular descriptions of agile programming provide much guidance on how to go about doing that.
There's also the fact that software development isn't a sprint, it's a marathon. It's like you're going to walk to a baseball game in a distant city. When you set out, you may not know what section, row, and seat number you're going to sit in, but it's kind of important to know whether you're going to PETCO Park or Soldier Field. (And, yes, I am fully aware that Soldier Field is a football stadium.) Big projects are made up of small decisions and each one of those decisions must be made in full awareness of the path you're walking.
So, as near as I can tell, the two essential rules are these: First, one should implement the essential functionality first. The problem, of course, is that "essential functionality" is hard to define. Second, it is vitally important to guess the complexity of the ultimate result before you begin, and if you are going to guess wrong it's better to guess that the job will be more complex than it turns out to actually be.
Putting those two rules together, I get "design complex, implement simple". This goes along with most of the design advice you see (avoid global variables, abstract things into functions, break your program up into logical chunks, define interfaces and then stick to them, and so forth) and also matches XP's don't implement stuff that's not in the requirements right now. It's not that you implement features in advance of their need, it's that you try to make it easy to implement whatever it turns out you need to implement.
Oh, I understand completely why people don't review code. It's because the reviewer has an impossible job. It's tough enough to figure out what the code does after hours of study, but your typical reviewer has a few minutes not only to understand the patch in the context of the code around it, but also to approve or reject each patch. Since that isn't enough time to determine whether or not the code is actually any good, my experience has been that most patches are approved because they're most likely correct. Add to that the fact that inspection of the source code has proven time and again to be the poorest way of finding defects, and one must conclude that code reviews are a pointless time-wasting exercise
While you are right that writers of prose have editors, the job of an editor of prose is not even approximately the same as the job of reviewer of software patches. At the grossest level, an editor's job is to issue syntax errors like the compiler does when you write programs in a compiled language. Also, the editor represents the publisher's and the readers' interests. Since books have to be within a fairly narrow range of sizes or they sell poorly, and magazines have a limited amount of space for editorial content, the editor might suggest that a story should be shortened in order to be salable or would have to reject articles due to the fact that they don't fit in well with the rest of the issue. There are equivalents to those jobs in the software industry, but they're not filled by a reviewer of source code.
Were you aware that the voltage regulator used in automotive applications works by varying the current to the field coils of the alternator? Apparently, not.
What do I think of GM? Not much. I certainly wouldn't be looking to invest in them because they have a lot of baggage that is going to be difficult for them to deal with. In my opinion the main difference between GM and Tesla is not that GM is viable and Tesla is not, but that GM has a track record so it's amenable to the sorts of analysis that can be derived from the very numbers that you point to, but Tesla really doesn't. In other words, you can find financials for GM on yahoo, but where do I find similar numbers, going back several years to establish a trend, for Tesla Motors? That puts them in a much stronger position with banks than you seem to realize.
Well, I will agree that the difference between prototype and production is more attitude than anything else. Like the difference between "beta" and "release", there aren't any hard and fast rules about what the difference really is. I will also admit that I was fooled by the fact that their article implies that their factory has yet to be built. However, the way Tesla builds their production vehicles looks (to me) very much like the way Ford or GM builds prototypes, and in about the same quantities.
Tesla motors has no proven ability to make anything except prototypes. It costs a lot of money to start a car company, because the factories are so expensive, and recouping the tooling costs requires that you amortize that cost over a large production run, which a startup really can't do because they have very little of the supporting infrastructure (dealers, trained mechanics, etc.) in order to be able to sell what they make to a mass audience.
What that means is that Tesla was always and still remains a long shot at being a viable company. At the present time, all Tesla has is a prototype and a story while GM has a lengthy history of actually building a lot of cars and making a profit by selling them. That is why Tesla has trouble getting financing while GM has less trouble. GM has assets they can sell and lots of momentum behind them. What does Tesla have except a following among the sort of people who regularly visits Slashdot?
You don't need to imagine a conspiracy to see why this is so, only a view of history. There is a long history of even established auto manufacturers finding it difficult to enter new markets. Remember Renault or Sterling (nee Rolls Royce)? Well, you probably don't, not as manufacturers that sell cars in the United States, anyway. The thing is, they both tried to enter the North American market and both were pretty dismal failures.
In fact, I remember reading an article praising the virtues of the cars made by Gordon-Keeble, which is a sports car manufacturer that you've probably never heard of. That car was actually put into production to be sold into exactly the market that the Tesla is targeting at about the same real cost, and without requiring the invention of a lot of the new technology that had to be invented for the Tesla. Despite the relative advantages (relative to mass market electric cars, I mean) it enjoyed, it eventually failed because it wasn't viable.
Most big-ticket manufacturing items are like that. It's tough to start a new company to build aircraft, for example, or ships or trucks. New entries face higher costs and can hope for much lower revenues than their more established competitors, and because of that a little thing like higher interest rates (in the late 1970's, the interest rates on mortgages were in the 20% range) can spell the end of a hopeful company while a larger company has the resources to weather the storm.
"A year spent in artificial intelligence is enough to make one believe in God." Alan J. Perlis
I have no idea what the right algorithm is, and neither do you. The fact that hundreds of the brightest minds in computing have spent decades on the problem of artificial intelligence and haven't made very much real progress supports the argument that the most commonly taken approach is wrong. Since that approach is based on Turing machines, to me it certainly seems possible, even probable, that there is some limitation of the underlying computer that makes AI impossibly difficult.
Are you saying that all technology must advance despite the fact that newer technology doesn't work as well in as many different circumstances? May as well require that everyone buy a new car every year because new cars have newer technology.
Actually, yes I have. More than a decade ago, I was one of the first people to get digital cable in Houston. When I first got it, it steadfastly refused to work at all. After three trips out by one of Time Warner's technicians, I was able to get the digital signal. Mostly. The thing is, after they cleaned up the cable signal enough that I was able to get digital TV at all, the analog picture was simply fabulous. However, sometimes the digital TV would disappear. Every time that would happen, I'd switch to an analog channel and the only obvious difficulty was some sparklies on the screen that I wouldn't have noticed except that I was looking for them.
More recently, I switched to an all digital service (Dish Network, as it happens) and it will sometimes be subject to rain fade. That means getting artifacts on the screen and crappy audio before (usually) failing completely.
Of course, as others have pointed out, the screen doesn't just fail with a marginal signal. If I may be allowed to amend my original statement, the binary "all or nothing" is a micro effect, while the macro effect is progressive disruption of the picture, possibly including periods of no picture at all. I still maintain that a snowy picture is more watchable than a video stream that consists of bursts of pixellated artifacts, but I acknowledge that opinions vary.
From my perspective, the real problem with digital television is that they're trying to satisfy several mutually-contradictory goals. In particular, they're trying to reduce the bandwidth consumed by the television signal while at the same time boosting the resolution of the picture.
Now, forgive the math, but it's pretty easy to show that that's not possible in the typical case without doing some sort of compression of the video signal. Assuming that pixels are square, an NTSC video signal is roughly the equivalent of 640x480 pixel frames at 30 frames per second. That is 9,216,000 pixels per second. The question, then, becomes "how many bits per pixel?" For color TV, I would expect that the minimum you could get away with is about 18 bits per pixel, meaning that a naive encoding would require about 165,888,000 bits per second throughput. Using FSK signalling for that signal requires a bandwidth of roughly twice that, or about 330 MHz per channel, which is somewhat larger than the 6 MHz (or so) per channel of an NTSC analog color TV signal.
Of course, they're not using FSK, so they're not encoding a single bit per symbol. My understanding is that they're using QAM which is commonly used to encode up to 8 bits per symbol. That reduces the bandwidth required (for the equivalent of NTSC video) to about seven times the bandwidth required for NTSC video. The only way to reduce it further is to aggressively compress that signal. Because most video signals are either highly compressible, or of such content that you don't really care whether or not you can see all the details (think panning across a detailed background,) a video signal would seem to be well suited to aggressive compression.
Of course, that "seeming" totally ignores the analog aspects of the transmission. You see, the more bits per symbol you have, the worse your QAM modulation works in the presence of noise, and aggressive compression means that screwing up a single bit means many more than one pixel will be screwed up in your output video. Of course, you can use forward error-correction, but adding in a little bit of redundancy in the form of forward error-corrective coding doesn't help make the signal very robust compared to an analog signal when you're you're using various technical means to remove the massive redundancies inherent in the analog signal.
The thing is, analog terrestrial broadcast is often quite noisy, due, in no small part, to the fact that terrestrial propagation depends upon the particular combination of terrain, buildings, and vehicles near to the transmitter and the receiver, and due to the fact that there are many devices i
No, it is not a myth. The most powerful part of an analog TV signal is the sync part so if you have any video at all, you have a picture that is synchronized to the transmitter. That means that the picture "stays still" if you can see it at all.
The problem with digital is that whether or not you see anything is a binary condition. Either you get perfect signals, or you get nothing. With analog, you have the choice of doing rabbit ears and putting up with snow or putting in a better antenna and seeing a much better picture. With digital, you must choose the more elaborate system or you get nothing at all. In many cases, switching to digital means that people will forced to install a more elaborate antenna system and many of those who do will still get no signal at all. This is why I've been critical of the decision to switch to digital transmissions for terrestrial television broadcasts. I think that most people do not value the image quality as highly as the digital television advocates do, and who cares how pretty the picture is if you can't see it?
I don't think it has anything to do with the mentation, or lack therein, of "the public". On the contrary, it can be difficult for anyone to tell which statements are "completely unfounded" and which statements have a germ of truth in them, and which statements are as close to fact as it is possible to be. The tricky bit is that what you know about the truth changes depending on what you hear. The whole point behind defamation is that new information can cause people to reevaluate what they think of as truth, and that's exactly what's supposed to happen. That reevaluation is an essential part of how everyone makes sense out of the masses of conflicting information they receive all day every day.
For my own part, I don't believe in absolute rights. That is, I believe that there there is no choice that is always right. It is not always right to speak. It is not always right to secure your person or your property. Was there an abuse of power in this case? Maybe, but I have a hard time getting worked up about it. If this is the best infringement of the right to free speech you can find in this country, then we don't, as a country, have a lot to complain about. I mean, like the suppression of the protesters of the political conventions, the fact that this MySpace page came to the Attention of the Authorities, and that Something was Done, seems to have had no effect on whether or not the speech was heard. In fact, the suppression seems to have had the opposite effect. In fact, I'd expect that the student has become somewhat uncomfortable with the tempest her little joke has wrought. That may be the real lesson that needs to be taken away: While pinatas and hornet's nests share a superficial resemblance, it is not a good idea to mistake one for the other.
On the other hand, if people don't raise issues like this one, and bring them to the fore, then we really may have a lot to complain about and, in that case, we might find out that we have no voice with which to complain, so I can't get all worked up about it being talked about, either, and that's one opinion, worth what you paid for it.
If you want a well-funded NASA, be sure to write your congresscritter. Say what you want about the president, he doesn't write nor does he pass the appropriations bills.
While your post had some over-the-top elements, I couldn't figure out if you were being sarcastic or just clueless. In any case, my post was meant, not as a rant, but as advice. If you choose to, you can apply your problem-solving skills to having a nice life without ever having to work again. Other geeks have done it, why not you?
We're smarter than them. In the geeky, pure-intellect, tough-maths-problem way.
No, you're not. You see, that attitude right there, that's what they call 'arrogance'. My experience suggests that they're not any dumber than you and they don't solve any less problems than you and many of them aren't less mathematical than you. For some reason, people tend to think those who work in, on, and with computers are particularly smart, but it isn't so.
If you want to have more money, drive the cool cars, and travel around the world, then maybe you should focus your crazy mad elite problem-solving skills on the problem of wanting more money and not wanting to work vastly more hours to get it. That sounds like it would be a really interesting problem for you to solve. I'm hardly a good person to give advice about the subject, because I still do the programming gig, but it seems to me that a smart person ought to be able to figure out how to accumulate sufficient wealth that he shouldn't have to work again. The thing is, that would mean making a substantial change in how you live. Are you prepared to do that? Most people will keep a crappy life rather than risk a change to something that might be better. Are you any different?
My experience has been that when they come for the engineers, it's usually to offer them bucketloads of money to come out of retirement because said engineer has some skill that is no longer common.
Send me? But I don't care one way or the other about the topic! Otherwise, I would do as I suggested and attempt to weaken the examples you've given by finding faults in them.
If you think the subject might come up again, then you might put the various links you've found onto a Web page where it will be handy the next time you want to support that position.
If you assert that a practice is widespread, then it should be possible, easy in fact, for you to come up with a single instance of that practice to support your assertion. Indeed, if you're taking the position that a practice is widespread, then you should be prepared to come up with a variety of examples of that practice, and be prepared to answer criticisms about those examples. Criticisms of the examples might include, but in no case must be limited to: The supporting evidence was faulty, the practice is not widespread but only happens in limited jurisdictions, the practice was common and has stopped being common, the example you gave is not really an example of the practice that you're talking about, and so forth.
If you're making an argument, then it is up to you to support it. I'm not going to take seriously anyone who supports his argument with a "you need to do your research" rebuttal. That's just lazy. I understand that you're responding to someone who is using his own experience as evidence, and that's weak, but the response you give is even weaker.
Slashdot Mirror
Anyway, in the mid-1990's there was a joke going around. I first heard it from my friend the FreeBSD fan. The joke?
At about the time that joke came out, the FSF engaged in a major effort to get the GNU/HURD to boot. After many months of work, you could kind of get it to run, but it was in no way useful. Shortly after, rms started insisting that people call Linux GNU/Linux.
It sure looks like the major effort was a response to that joke and, when that effort failed, they decided to respond to the punchline "Linux has a kernel that boots" with "no, Linux IS a kernel that boots." I presume they thought that devastating. To me, it seemed pathetic. I mean, with all of their resources and more than a decade of work, they weren't able to do what Linus Torvalds did all by himself in a few weeks. I think that it's an excellent example of how hard "big bang" development is when compared to a more incremental style.
100Km is about 328,000 feet. That's why Space Ship One had a tail number of N328KF.
Also, the North Texas Balloon Team and the South Texas Balloon Project routinely (with launches approximately annually) send balloons with video cameras to altitudes in excess of 100,000 feet. Those are just the two balloon projects I'm familiar with. I am sure there are others because it's not particularly hard to do.
So, this is pure ho-hum to me. Let me know when they've done it a couple of dozen times.
I could never do anything in Railroad Tycoon II except run out of money, but I was just running Civilization: Call to Power last night on my 64-bit Debian box last night, so what's all this noise about nothing working?
Ummm, Sanka is like the original decaffeinated coffee.
Actually, it's not that hard, at least if you're running Apache. You simply set up one server to receive all the incoming requests and then use Apache's proxy capability to forward the request to the server it should actually go to. My home network is like that. Actually, my home network also runs IPv6 and the IPv6 address resolves to the actual destination computer, but IPv6 connectivity being what it is (that is, nearly nonexistent) I needed to figure out how to make it work with the single IPv4 address I had.
The Windows memory manager knows far more than you do...
That reminds me of the oven in my house that apparently knows far more than I do about whether or not I want to bake anything. My intention is to replace it as soon as the repairs to fix the damage from hurricane Ike are complete, and I'm going to replace it with the dumbest appliance I can find.
Look, I know the logic that that says that since RAM is a scarce resource a virtual memory manager must be running at all times to properly manage that scarce resource. I read about it the last time it came up on Slashdot, and, well, I didn't believe it then, either. Oh, I believe the assertion that a scarce resource must be carefully managed. It's just that I no longer believe that semiconductor RAM is particularly scarce. I mean, if I could demonstrate that all of my programs' working sets and all of the file data that they're going to access can all fit in RAM at once, then wouldn't you agree that virtual memory management is unnecessary?
Of course, demonstrating that everything is going to fit in semiconductor RAM is not a trivial task, but I can't help but think that caching a lot of most large files is pretty useless. I mean, if you're streaming a video of a movie, you need to prefetch enough of it that you don't have to worry about underruns and once you've played a frame there's no point in keeping it around any longer, so I would think that 100 MB of buffer would suffice for videos that are gigabytes long and 100 MB is 2.5% of the memory in a computer that has 4G of semiconductor RAM. That implies that the bulk of the benefit of caching comes from caching small files, like the intermediate files generated when compiling or processing email or stuff like that.
Of course, my not believing something doesn't make it false, but I'd still like to see some more effort placed into demonstrating that semiconductor RAM remains a scarce resource. I'm afraid that your bittorrent seeding example suggests to me rather the opposite: RAM on your machine is so plentiful that you have to seed a hundred Linux ISOs to make it scarce.
I'm glad it works well for you. Still, I can't help but wonder what you would find if you gathered statistics about those errors found by inspection as opposed to those errors that inspection failed to find and had to be found some other way. Would you determine that the effort is worth the time? I wonder.
As it happens, last Friday I had occasion to do review some code. You see, I had discovered that something was causing an error in my client-facing API code and by reviewing the thrust of all of the changes in Subversion, I concluded that the error had to be in a particular function and the code that had been last changed in that function was not too long, only a dozen lines or so. The code was written by someone who is perhaps the best programmer in the place, and it was properly formatted and in the same style as the rest of the code. However, I knew that the change in question was badly broken as I was reviewing the code and I couldn't see the error.
It was only as I dug deeper than a review could cover, and took advantage of the additional information from my knowledge of the symptoms to conclude that a particular branch that should have been taken was not, in fact, being taken, which lead me to realize that a particular variable was not being properly initialized in a loop. That code should have been moved out of the loop when the code was reorganized and simplified, but it had not been, which resulted in the error.
In addition to the timing, I find this defect interesting for two reasons. First, because an inspection would have utterly failed to detect that the change was broken. I mean, I looked right at the code and couldn't see it despite being familiar with the context and such and armed with the knowledge that it contained an error. Second, this sort of flubbing up a reorganization is a common error when writing prose.
The whole "clearly defined requirements" thing is a straw man, as you well know. I have found that specifications are always subject to change and so you need a methodology that can deal with that. The thing is, I have not found that the popular descriptions of agile programming provide much guidance on how to go about doing that.
There's also the fact that software development isn't a sprint, it's a marathon. It's like you're going to walk to a baseball game in a distant city. When you set out, you may not know what section, row, and seat number you're going to sit in, but it's kind of important to know whether you're going to PETCO Park or Soldier Field. (And, yes, I am fully aware that Soldier Field is a football stadium.) Big projects are made up of small decisions and each one of those decisions must be made in full awareness of the path you're walking.
So, as near as I can tell, the two essential rules are these: First, one should implement the essential functionality first. The problem, of course, is that "essential functionality" is hard to define. Second, it is vitally important to guess the complexity of the ultimate result before you begin, and if you are going to guess wrong it's better to guess that the job will be more complex than it turns out to actually be.
Putting those two rules together, I get "design complex, implement simple". This goes along with most of the design advice you see (avoid global variables, abstract things into functions, break your program up into logical chunks, define interfaces and then stick to them, and so forth) and also matches XP's don't implement stuff that's not in the requirements right now. It's not that you implement features in advance of their need, it's that you try to make it easy to implement whatever it turns out you need to implement.
Oh, I understand completely why people don't review code. It's because the reviewer has an impossible job. It's tough enough to figure out what the code does after hours of study, but your typical reviewer has a few minutes not only to understand the patch in the context of the code around it, but also to approve or reject each patch. Since that isn't enough time to determine whether or not the code is actually any good, my experience has been that most patches are approved because they're most likely correct. Add to that the fact that inspection of the source code has proven time and again to be the poorest way of finding defects, and one must conclude that code reviews are a pointless time-wasting exercise
While you are right that writers of prose have editors, the job of an editor of prose is not even approximately the same as the job of reviewer of software patches. At the grossest level, an editor's job is to issue syntax errors like the compiler does when you write programs in a compiled language. Also, the editor represents the publisher's and the readers' interests. Since books have to be within a fairly narrow range of sizes or they sell poorly, and magazines have a limited amount of space for editorial content, the editor might suggest that a story should be shortened in order to be salable or would have to reject articles due to the fact that they don't fit in well with the rest of the issue. There are equivalents to those jobs in the software industry, but they're not filled by a reviewer of source code.
Were you aware that the voltage regulator used in automotive applications works by varying the current to the field coils of the alternator? Apparently, not.
What do I think of GM? Not much. I certainly wouldn't be looking to invest in them because they have a lot of baggage that is going to be difficult for them to deal with. In my opinion the main difference between GM and Tesla is not that GM is viable and Tesla is not, but that GM has a track record so it's amenable to the sorts of analysis that can be derived from the very numbers that you point to, but Tesla really doesn't. In other words, you can find financials for GM on yahoo, but where do I find similar numbers, going back several years to establish a trend, for Tesla Motors? That puts them in a much stronger position with banks than you seem to realize.
Well, I will agree that the difference between prototype and production is more attitude than anything else. Like the difference between "beta" and "release", there aren't any hard and fast rules about what the difference really is. I will also admit that I was fooled by the fact that their article implies that their factory has yet to be built. However, the way Tesla builds their production vehicles looks (to me) very much like the way Ford or GM builds prototypes, and in about the same quantities.
Tesla motors has no proven ability to make anything except prototypes. It costs a lot of money to start a car company, because the factories are so expensive, and recouping the tooling costs requires that you amortize that cost over a large production run, which a startup really can't do because they have very little of the supporting infrastructure (dealers, trained mechanics, etc.) in order to be able to sell what they make to a mass audience.
What that means is that Tesla was always and still remains a long shot at being a viable company. At the present time, all Tesla has is a prototype and a story while GM has a lengthy history of actually building a lot of cars and making a profit by selling them. That is why Tesla has trouble getting financing while GM has less trouble. GM has assets they can sell and lots of momentum behind them. What does Tesla have except a following among the sort of people who regularly visits Slashdot?
You don't need to imagine a conspiracy to see why this is so, only a view of history. There is a long history of even established auto manufacturers finding it difficult to enter new markets. Remember Renault or Sterling (nee Rolls Royce)? Well, you probably don't, not as manufacturers that sell cars in the United States, anyway. The thing is, they both tried to enter the North American market and both were pretty dismal failures.
In fact, I remember reading an article praising the virtues of the cars made by Gordon-Keeble, which is a sports car manufacturer that you've probably never heard of. That car was actually put into production to be sold into exactly the market that the Tesla is targeting at about the same real cost, and without requiring the invention of a lot of the new technology that had to be invented for the Tesla. Despite the relative advantages (relative to mass market electric cars, I mean) it enjoyed, it eventually failed because it wasn't viable.
Most big-ticket manufacturing items are like that. It's tough to start a new company to build aircraft, for example, or ships or trucks. New entries face higher costs and can hope for much lower revenues than their more established competitors, and because of that a little thing like higher interest rates (in the late 1970's, the interest rates on mortgages were in the 20% range) can spell the end of a hopeful company while a larger company has the resources to weather the storm.
"A year spent in artificial intelligence is enough to make one believe in God." Alan J. Perlis
I have no idea what the right algorithm is, and neither do you. The fact that hundreds of the brightest minds in computing have spent decades on the problem of artificial intelligence and haven't made very much real progress supports the argument that the most commonly taken approach is wrong. Since that approach is based on Turing machines, to me it certainly seems possible, even probable, that there is some limitation of the underlying computer that makes AI impossibly difficult.
Are you saying that all technology must advance despite the fact that newer technology doesn't work as well in as many different circumstances? May as well require that everyone buy a new car every year because new cars have newer technology.
Actually, yes I have. More than a decade ago, I was one of the first people to get digital cable in Houston. When I first got it, it steadfastly refused to work at all. After three trips out by one of Time Warner's technicians, I was able to get the digital signal. Mostly. The thing is, after they cleaned up the cable signal enough that I was able to get digital TV at all, the analog picture was simply fabulous. However, sometimes the digital TV would disappear. Every time that would happen, I'd switch to an analog channel and the only obvious difficulty was some sparklies on the screen that I wouldn't have noticed except that I was looking for them.
More recently, I switched to an all digital service (Dish Network, as it happens) and it will sometimes be subject to rain fade. That means getting artifacts on the screen and crappy audio before (usually) failing completely.
Of course, as others have pointed out, the screen doesn't just fail with a marginal signal. If I may be allowed to amend my original statement, the binary "all or nothing" is a micro effect, while the macro effect is progressive disruption of the picture, possibly including periods of no picture at all. I still maintain that a snowy picture is more watchable than a video stream that consists of bursts of pixellated artifacts, but I acknowledge that opinions vary.
From my perspective, the real problem with digital television is that they're trying to satisfy several mutually-contradictory goals. In particular, they're trying to reduce the bandwidth consumed by the television signal while at the same time boosting the resolution of the picture.
Now, forgive the math, but it's pretty easy to show that that's not possible in the typical case without doing some sort of compression of the video signal. Assuming that pixels are square, an NTSC video signal is roughly the equivalent of 640x480 pixel frames at 30 frames per second. That is 9,216,000 pixels per second. The question, then, becomes "how many bits per pixel?" For color TV, I would expect that the minimum you could get away with is about 18 bits per pixel, meaning that a naive encoding would require about 165,888,000 bits per second throughput. Using FSK signalling for that signal requires a bandwidth of roughly twice that, or about 330 MHz per channel, which is somewhat larger than the 6 MHz (or so) per channel of an NTSC analog color TV signal.
Of course, they're not using FSK, so they're not encoding a single bit per symbol. My understanding is that they're using QAM which is commonly used to encode up to 8 bits per symbol. That reduces the bandwidth required (for the equivalent of NTSC video) to about seven times the bandwidth required for NTSC video. The only way to reduce it further is to aggressively compress that signal. Because most video signals are either highly compressible, or of such content that you don't really care whether or not you can see all the details (think panning across a detailed background,) a video signal would seem to be well suited to aggressive compression.
Of course, that "seeming" totally ignores the analog aspects of the transmission. You see, the more bits per symbol you have, the worse your QAM modulation works in the presence of noise, and aggressive compression means that screwing up a single bit means many more than one pixel will be screwed up in your output video. Of course, you can use forward error-correction, but adding in a little bit of redundancy in the form of forward error-corrective coding doesn't help make the signal very robust compared to an analog signal when you're you're using various technical means to remove the massive redundancies inherent in the analog signal.
The thing is, analog terrestrial broadcast is often quite noisy, due, in no small part, to the fact that terrestrial propagation depends upon the particular combination of terrain, buildings, and vehicles near to the transmitter and the receiver, and due to the fact that there are many devices i
No, it is not a myth. The most powerful part of an analog TV signal is the sync part so if you have any video at all, you have a picture that is synchronized to the transmitter. That means that the picture "stays still" if you can see it at all.
The problem with digital is that whether or not you see anything is a binary condition. Either you get perfect signals, or you get nothing. With analog, you have the choice of doing rabbit ears and putting up with snow or putting in a better antenna and seeing a much better picture. With digital, you must choose the more elaborate system or you get nothing at all. In many cases, switching to digital means that people will forced to install a more elaborate antenna system and many of those who do will still get no signal at all. This is why I've been critical of the decision to switch to digital transmissions for terrestrial television broadcasts. I think that most people do not value the image quality as highly as the digital television advocates do, and who cares how pretty the picture is if you can't see it?
I don't think it has anything to do with the mentation, or lack therein, of "the public". On the contrary, it can be difficult for anyone to tell which statements are "completely unfounded" and which statements have a germ of truth in them, and which statements are as close to fact as it is possible to be. The tricky bit is that what you know about the truth changes depending on what you hear. The whole point behind defamation is that new information can cause people to reevaluate what they think of as truth, and that's exactly what's supposed to happen. That reevaluation is an essential part of how everyone makes sense out of the masses of conflicting information they receive all day every day.
For my own part, I don't believe in absolute rights. That is, I believe that there there is no choice that is always right. It is not always right to speak. It is not always right to secure your person or your property. Was there an abuse of power in this case? Maybe, but I have a hard time getting worked up about it. If this is the best infringement of the right to free speech you can find in this country, then we don't, as a country, have a lot to complain about. I mean, like the suppression of the protesters of the political conventions, the fact that this MySpace page came to the Attention of the Authorities, and that Something was Done, seems to have had no effect on whether or not the speech was heard. In fact, the suppression seems to have had the opposite effect. In fact, I'd expect that the student has become somewhat uncomfortable with the tempest her little joke has wrought. That may be the real lesson that needs to be taken away: While pinatas and hornet's nests share a superficial resemblance, it is not a good idea to mistake one for the other.
On the other hand, if people don't raise issues like this one, and bring them to the fore, then we really may have a lot to complain about and, in that case, we might find out that we have no voice with which to complain, so I can't get all worked up about it being talked about, either, and that's one opinion, worth what you paid for it.
If you want a well-funded NASA, be sure to write your congresscritter. Say what you want about the president, he doesn't write nor does he pass the appropriations bills.
While your post had some over-the-top elements, I couldn't figure out if you were being sarcastic or just clueless. In any case, my post was meant, not as a rant, but as advice. If you choose to, you can apply your problem-solving skills to having a nice life without ever having to work again. Other geeks have done it, why not you?
No, you're not. You see, that attitude right there, that's what they call 'arrogance'. My experience suggests that they're not any dumber than you and they don't solve any less problems than you and many of them aren't less mathematical than you. For some reason, people tend to think those who work in, on, and with computers are particularly smart, but it isn't so.
If you want to have more money, drive the cool cars, and travel around the world, then maybe you should focus your crazy mad elite problem-solving skills on the problem of wanting more money and not wanting to work vastly more hours to get it. That sounds like it would be a really interesting problem for you to solve. I'm hardly a good person to give advice about the subject, because I still do the programming gig, but it seems to me that a smart person ought to be able to figure out how to accumulate sufficient wealth that he shouldn't have to work again. The thing is, that would mean making a substantial change in how you live. Are you prepared to do that? Most people will keep a crappy life rather than risk a change to something that might be better. Are you any different?
My experience has been that when they come for the engineers, it's usually to offer them bucketloads of money to come out of retirement because said engineer has some skill that is no longer common.
Send me? But I don't care one way or the other about the topic! Otherwise, I would do as I suggested and attempt to weaken the examples you've given by finding faults in them.
If you think the subject might come up again, then you might put the various links you've found onto a Web page where it will be handy the next time you want to support that position.
If you're making an argument, then it is up to you to support it. I'm not going to take seriously anyone who supports his argument with a "you need to do your research" rebuttal. That's just lazy. I understand that you're responding to someone who is using his own experience as evidence, and that's weak, but the response you give is even weaker.