Oops--you're absolutely right, of course. Boy, I must have not been paying attention when I typed that---how embarassing. s/C/Java/ and thanks for the correction!
First, thanks much for the cool book ref! It looks very nice.
That said, I think a little more of a depth discussion would make the conventional description of the current PL situation with dynamic checks more clear.
A traditional view of types, due to Strachey and Scott, is that a type is defined by the set of possible values that comprise it. As such, one might reasonably say that the operand type of the right hand operand of the C short int divide operator "/" is the set {-32768..32767}-{0} (given 16-bit shorts, but don't get me started).
In practice, however, and motivated by the above example, programming languages tend to restrict the set of types usable in programming. One usual consequence of this restriction is that static typechecking moves from being undecidable to being tractable. Another is that some valid programs are excluded by the type system.
The statement in the Java programming language reference manual that "the runtime type system cannot be subverted by code written in the language" is not limiting. Indeed, Chapter 4 of the spec makes it clear that it considers the base types of the language to be only those "standard" types that any first-year programming student would expect. Section 15.5 makes it clear that integer division by 0 is not regarded as a type error in Java. Instead, 0 is a legally-typed right operand for the Java integer divide operator---it merely causes a runtime exception to be raised when it is encountered. From the perspective of most normal folks, this is the same as saying "there's a runtime operand check for a right-hand side of 0, and an error is raised (but may be handled) when it occurs."
There are other views than the standard one of what a type is. A quite modern view is to regard "types" as a synonym for "properties" of a computation. This view leads to some interesting programming language ideas, but they're still pretty much in the research stage. Note also that the Strachey-Scott view is in some sense the one rejected by parent: that types are defined by the axioms and inference rules of a type system. It's just that Dana Scott's work on domain theory allows such a definition to be sound.
We're pretty badly off-topic here, but what the hey...
C was first designed and implemented in the time period from 1969-1973. It is hardly a critique of its original designers and implementors that we have learned a lot about programming language design and implementation in the succeeding 30+ years, and that many of the constraints of the computing environment have been weakened or removed during that time. Indeed, some of the original designers of C and UNIX spent a lot of time 10+ years ago developing an alternative language and runtime for writing operating system and application code that fixes the problems with C that I described.
"In fact, when you are coding things like process and memory mangement routines and libraries, it is very handy to be able to do arithmetic with and compare to variables that are not "exactly" the same type, if the comparison or operation otherwise makes sense. Hence, things like the boolean FALSE and integer 0 being equal (which Java will complain about) are handy."
If by "handy", parent meant "tempting" but "error-prone" and "potentially insecure", I think there's about 30 years' experience to back up this claim. Things as fundamental or important as my operating system's process or memory management routines are occasionally broken in particularly dangerous ways because their programmer did something that seemed to "make sense" at the time, even though a "safe" programming language wouldn't allow it. Go look at the changelogs of a recent UNIX kernel for plenty of examples.
"The lack of dynamic type checking, operand checking and bounds checking allows the programmer to write low level or system code that gets out of the way of higher level code." I'm sorry, but I don't know what this means.
"Imagine the performance degradation at the kernel if every comparison was dynamically checked for type, operand and bounds." One would prefer that operations be checked statically whenever possible. This is not so much for performance as because failed runtime checks in low-level code are difficult to handle gracefully. That said, as I mentioned in my previous post on this topic, we have known for a long time how to build programming languages so that a combination of static and runtime type and operand checking will provide some correctness guarantees without signficantly impacting execution performance. IMHO, it's way past time to start using that knowledge.
Why does this topic bring the, uh, technically challenged out of the woodwork?
I'm a Ph.D. computer science professor with 20 years of experience in design and implementation of programming languages, and the co-author of a C-like programming language featuring static and dynamic typing and runtime operand checking. The parent poster is confused.
Static type checking involves automatically recognizing type-unsafe operations at compile time. In many programming languages, including C, if you write"s" - 1 the + operation is ill-defined, because the left-hand operand is of the wrong type: i.e., there is no string that is a legal operation to the - operator. The compiler can detect this at compile time and refuse to compile the program.
Dynamic type checking involves automatically recognizing type-unsafe operations at run time. In many programming languages, such as Python, if you write"s" - 1 inside a function definition, the compiler will not detect the problem, because the general problem of detecting this kind of error is unsolvable unless one restricts what programmers can write. Instead, the execution engine can detect the problem at runtime when the - is evaluated and refuse to continue executing the program.
Runtime operand checking involves automatically recognizing at runtime that an operation has an operand that, while of a type that might be legal for the operation being performed, is nonetheless illegal for that operation. In many languages, including Python, if you write
1 / 0
no error will be reported at compile time, because detecting such errors is in general impossible. Instead, the execution engine can detect the problem at runtime, and prevent execution from continuing.
(Of course, there also is such a thing as static operand checking, which bears the same relation to runtime operand checking that static type checking does to runtime type checking. This is a hot research topic right now.)
C's problem is that it (a) does not have a "safe" static type system, (b) does not have any dynamic type checking, and (c) has no operand checking. This combination of misfeatures is incredibly and obviously error-prone; offhand, I can think of no other popular language (not derived from C) that is broken in this fashion. Fixing (a) and/or (b) is not sufficient---(c) also needs to be fixed. Java, for example, has shown that this can be done in a C-like compiled language without noticeable loss of efficiency. (This was shown for PL/I more than 30 years ago, so it's no surprise.)
The parent post gives an example in which the index argument to an array dereference is of the correct type and has correct operands. If x[2] was evaluated, this would be an operand error, since the combination of arguments x and 2 is not a legal operand combination for the array dereference operator. With the statement as given in the parent post, I'm not sure what principle it was trying to illustrate. I think, though, that it doesn't much matter.
Re:Ah yes, the one with the MAC address thing
on
DECnet Isn't Dead
·
· Score: 1
Uh, yeah. I was being sarcastic when I called it "cool"---it was a horrible idea. Sorry it didn't come through in the original message.
Ah yes, the one with the MAC address thing
on
DECnet Isn't Dead
·
· Score: 3, Insightful
Yeah, I remember DECnet. The coolest thing about it is that it required you to have a special DECnet MAC address for every Ethernet port on each host. The good news is that this led to widespread Ethernet MAC reprogrammability...
I've yet to have even read an SF novel in which a ship travels faster than light by accellerating a normal mass beyond the speed of light while keeping that mass within normal spacetime, and I've read hundreds of science fiction novels.
One could make a case for Vernor Vinge's A Fire Upon The Deep. The objection that the
Beyond isn't normal spacetime is easily answered with a simple "how do you know?"
This is, of course, the larger question. The lightspeed limit is still based on a surprisingly large amount of speculation. No one has ever directly observed anything like a Kg of mass accelerated to 0.98c. Maybe our extrapolations from high-velocity nanomasses and high-mass nanovelocities don't hold for large masses at high velocity? Heaven knows that classical mechanics got thoroughly corrected for nanoscales and high velocities when we were finally able to observe these phenomena "directly".
So why are SF writers so wormhole-obsessed? I say just declare 21st-century physicists wrong about the whole FTL thing, and move on.
So I asked, "What's the problem?" She replied, "I can't tell you. I don't even know you..." I said, "Well sometimes it's good to tell your problems to a perfect stranger on a bus." ---Steven Wright
Uh, no. A little math, assuming a constant 3.1% annual inflation rate, shows that there were 14 $100M (1970 dollars) grossing films in the 70s, 13 in the 80s, and 8 from 1990-1995. So statistically, inflation really does predict the whole story.
Uh, a US letter currently doesn't have to have a return address, much less a validated one. And a public mailbox in a big US city is pretty darn anonymizing. After all, they still haven't caught the folks who sent anthrax-filled letters to US government officials---and I'm guessing it's not for want of trying.
You should be suspicious of this rationale, since it is ridiculous if carried to the extreme. Books and chalkboards, after all, are only "technological crutches" for learning, as are heated and air-conditioned classrooms with artificial light.
The bottom line is that something like 80% of the expenses at a typical American high school or college are salaries. If you can spend $2000 on anything that makes a classroom teacher being paid $30000/year even slightly more productive, you've probably won. After all, it only takes a 2% productivity gain over 3 years to break even.
Does this same logic make it stupid not to maintain and improve buildings? You bet: arguably even more so. But it's not an intuitive tradeoff to most people for some reason, even though the math is quite easy to understand. I think a lot of it is simple, if misguided, inherency. "If charcoal on the back of a wooden shovel was good enough for Abe Lincoln, it's good enough for my kid."
How is this insightful? I'm a Ph.D. computer scientist with more than 20 years computing experience in a variety of areas. I have a long list of employers who will talk glowingly about my problem-solving skills. If RIM or Google or Microsoft or whoever tried to give me a puzzle-solving test in a job interview at this point in my career, I'd walk out.
One of my closest friends walked out of Sequent on this basis some years ago. He's now one of the most successful (and employable) computer people in the industry. As for Sequent...dead dead dead. Speaking of which, how is RIM doing these days?
Puzzle-solving tests in interviews may be appropriate for folks who haven't already solidly demonstrated their problem-solving skills in their application domain in some other way. For the rest of us, IMHO it's really a bit insulting; on the order of a hazing exercise. A certain class of manager will predictably reject folks who are unwilling to be hazed. I don't have much interest in working for those folks.
Future Shop is certainly not Fry's. I agree that FS's prices are usually poor and their sales tactics sometimes questionable. But in our town they aren't the competition for the small shops: Fry's is.
Yes, in my area the small shops are indeed the ex-furniture-dealer types:-). It sounds to me like your shop is exceptional. This is great, and I wish you all the best!
More expensive by what... $5/hard drive? $20/computer?
In my experience, small-shop hardware prices run typically about 50% more than Fry's, which means 60-70% more than bottom-dollar web merchants. And they typically stock 0.1-0.01 times the selection of Fry's. Thus, whenever I go in there, it's not likely they have what I want, and when they do it's priced so outrageously I leave anyway. Doesn't take much of that kind of reinforcement to keep me away.
I believe it could be better. Small computer+electronics merchants need to learn the virtues of broad+shallow inventories and better inventory targeting. They need to understand how to better use sale pricing as a promotional tool and to turn over inventory. They need to market to their local customers. They need to be open at the kind of hours folks actually shop for this stuff. All of these are things that have made Fry's successful in our area, and that small merchants can easily do. Then I'll try more often to buy something from them.
There's a move afoot to restrict the sale of high-bandwidth analog-to-digital and digital-to-analog converters in the US, since they are used by open software-defined radio (SDR) manufacturers to produce hardware that could easily circumvent the broadcast flag. This is scary and ridiculous at the same time: I'm not sure whether to hope the restriction fails (and ubiquitous SDR solves the broadcast flag problem) or succeeds (and the US becomes an noncompetitive joke in a whole range of industries, providing a valuable object lesson). No, wait---I'll take the first thing.
Offtopic: why does slashcode elide so many HTML entities, including — ? It's really annoying, and seems totally gratuitous to me.
Yep. Ability to ring the phone would be a key difference between the tiny $20 generic POTS product and the largish-looking $60 apparently-skype-only product:-):-).
The only disadvantage is that it's not like a real phone, it won't ring if someone calls you.
That's because a real US POTS line uses a 90VAC ring "signal" (actually provides power for an old mechanical ringer if you have one) and there are a lot of good reasons the Chatcord folks wouldn't want to generate that. Too bad, though.
The odd thing about the Scooba is that iRobot's first product was also a floor-cleaning machine. I've heard Rod Brooks tell this story in person a couple of times, and it cracked me up.
...the company first partnered with JohnsonDiversey (formerly Johnson Wax Professional) in 1998, with the goal of producing a robot floor cleaner. Commercial floor cleaning is roughly a $50 billion business. Angle says that any floor-cleaning system involves three things: sweep, scrub, and polish. No machine on the market did all three at once, but since iRobot developers didn't want to build three separate robots, they set about creating one that could do all three. The end result was the NexGen Multi-Function Floor Care machine. The success of that project led them to Roomba.
If you read between the lines here, you get the real story: they spent a lot of time building this three-function janitor-bot with a big computer in the middle to drive it around the building. They then started showing it to potential customers, every one of whom said the same thing: "A 3-function cleaning machine? That's fantastic! Take that computer out of the middle of it and put a handle on for the janitor and we'll buy a bajillion of 'em!"
So they did. The hole where the computer had been made nice storage. Better yet, iRobot had learned a valuable lesson about disruptive technologies: small steps.
Parent wrote "
My `public interest' would be nicely served by actually being able to get broadband. And I have power lines."
Which is why this stupid idea is so seductive. Everybody wants broadband, everybody has power lines. What's the problem?
(1) It doesn't work, and really can't work. (2) It has bad negative consequences for other systems (forget ham radio, and consider the emergency radio bands it overlaps). (3) Even if it did work, it would be more expensive and less available than current broadband channels.
I mean, everybody who wants broadband probably has water pipes, too. Why not broadband over tapwater? Pulse-modulate the chlorine and fluorine levels in the pipes, and read the bits right off there... BPL isn't much more sensible than BT when you look at it closely.
Nope. Read your GPL carefully. If func_mine_all_mine() is part of a GPL-ed program, you'll have to release its source anytime you release the binary to that program.
Now there's some controversy about what counts as "part of a GPL-ed program." Shared libraries? Kernel modules? Driver scripts? RMS and the FSF legal team, Linus Torvalds, and others have all released opinions on this, but so far I'm not aware of any court cases that have defined these limits legally. It may be that DN's lawyers think that they have a legal case for keeping some code out.
Slashdot Mirror
Nice rack!
Thanks, I'll be here all week...
Oops--you're absolutely right, of course. Boy, I must have not been paying attention when I typed that---how embarassing. s/C/Java/ and thanks for the correction!
We're way off-topic here, but still...
First, thanks much for the cool book ref! It looks very nice.
That said, I think a little more of a depth discussion would make the conventional description of the current PL situation with dynamic checks more clear.
A traditional view of types, due to Strachey and Scott, is that a type is defined by the set of possible values that comprise it. As such, one might reasonably say that the operand type of the right hand operand of the C short int divide operator "/" is the set {-32768..32767}-{0} (given 16-bit shorts, but don't get me started).
In practice, however, and motivated by the above example, programming languages tend to restrict the set of types usable in programming. One usual consequence of this restriction is that static typechecking moves from being undecidable to being tractable. Another is that some valid programs are excluded by the type system.
The statement in the Java programming language reference manual that "the runtime type system cannot be subverted by code written in the language" is not limiting. Indeed, Chapter 4 of the spec makes it clear that it considers the base types of the language to be only those "standard" types that any first-year programming student would expect. Section 15.5 makes it clear that integer division by 0 is not regarded as a type error in Java. Instead, 0 is a legally-typed right operand for the Java integer divide operator---it merely causes a runtime exception to be raised when it is encountered. From the perspective of most normal folks, this is the same as saying "there's a runtime operand check for a right-hand side of 0, and an error is raised (but may be handled) when it occurs."
There are other views than the standard one of what a type is. A quite modern view is to regard "types" as a synonym for "properties" of a computation. This view leads to some interesting programming language ideas, but they're still pretty much in the research stage. Note also that the Strachey-Scott view is in some sense the one rejected by parent: that types are defined by the axioms and inference rules of a type system. It's just that Dana Scott's work on domain theory allows such a definition to be sound.
Hope this helps.
We're pretty badly off-topic here, but what the hey...
C was first designed and implemented in the time period from 1969-1973. It is hardly a critique of its original designers and implementors that we have learned a lot about programming language design and implementation in the succeeding 30+ years, and that many of the constraints of the computing environment have been weakened or removed during that time. Indeed, some of the original designers of C and UNIX spent a lot of time 10+ years ago developing an alternative language and runtime for writing operating system and application code that fixes the problems with C that I described.
"In fact, when you are coding things like process and memory mangement routines and libraries, it is very handy to be able to do arithmetic with and compare to variables that are not "exactly" the same type, if the comparison or operation otherwise makes sense. Hence, things like the boolean FALSE and integer 0 being equal (which Java will complain about) are handy."
If by "handy", parent meant "tempting" but "error-prone" and "potentially insecure", I think there's about 30 years' experience to back up this claim. Things as fundamental or important as my operating system's process or memory management routines are occasionally broken in particularly dangerous ways because their programmer did something that seemed to "make sense" at the time, even though a "safe" programming language wouldn't allow it. Go look at the changelogs of a recent UNIX kernel for plenty of examples.
"The lack of dynamic type checking, operand checking and bounds checking allows the programmer to write low level or system code that gets out of the way of higher level code." I'm sorry, but I don't know what this means.
"Imagine the performance degradation at the kernel if every comparison was dynamically checked for type, operand and bounds." One would prefer that operations be checked statically whenever possible. This is not so much for performance as because failed runtime checks in low-level code are difficult to handle gracefully. That said, as I mentioned in my previous post on this topic, we have known for a long time how to build programming languages so that a combination of static and runtime type and operand checking will provide some correctness guarantees without signficantly impacting execution performance. IMHO, it's way past time to start using that knowledge.
Why does this topic bring the, uh, technically challenged out of the woodwork?
I'm a Ph.D. computer science professor with 20 years of experience in design and implementation of programming languages, and the co-author of a C-like programming language featuring static and dynamic typing and runtime operand checking. The parent poster is confused.
Static type checking involves automatically recognizing type-unsafe operations at compile time. In many programming languages, including C, if you write"s" - 1 the + operation is ill-defined, because the left-hand operand is of the wrong type: i.e., there is no string that is a legal operation to the - operator. The compiler can detect this at compile time and refuse to compile the program.
Dynamic type checking involves automatically recognizing type-unsafe operations at run time. In many programming languages, such as Python, if you write"s" - 1 inside a function definition, the compiler will not detect the problem, because the general problem of detecting this kind of error is unsolvable unless one restricts what programmers can write. Instead, the execution engine can detect the problem at runtime when the - is evaluated and refuse to continue executing the program.
Runtime operand checking involves automatically recognizing at runtime that an operation has an operand that, while of a type that might be legal for the operation being performed, is nonetheless illegal for that operation. In many languages, including Python, if you write 1 / 0 no error will be reported at compile time, because detecting such errors is in general impossible. Instead, the execution engine can detect the problem at runtime, and prevent execution from continuing.
(Of course, there also is such a thing as static operand checking, which bears the same relation to runtime operand checking that static type checking does to runtime type checking. This is a hot research topic right now.)
C's problem is that it (a) does not have a "safe" static type system, (b) does not have any dynamic type checking, and (c) has no operand checking. This combination of misfeatures is incredibly and obviously error-prone; offhand, I can think of no other popular language (not derived from C) that is broken in this fashion. Fixing (a) and/or (b) is not sufficient---(c) also needs to be fixed. Java, for example, has shown that this can be done in a C-like compiled language without noticeable loss of efficiency. (This was shown for PL/I more than 30 years ago, so it's no surprise.)
The parent post gives an example in which the index argument to an array dereference is of the correct type and has correct operands. If x[2] was evaluated, this would be an operand error, since the combination of arguments x and 2 is not a legal operand combination for the array dereference operator. With the statement as given in the parent post, I'm not sure what principle it was trying to illustrate. I think, though, that it doesn't much matter.
Uh, yeah. I was being sarcastic when I called it "cool"---it was a horrible idea. Sorry it didn't come through in the original message.
Yeah, I remember DECnet. The coolest thing about it is that it required you to have a special DECnet MAC address for every Ethernet port on each host. The good news is that this led to widespread Ethernet MAC reprogrammability...
I've yet to have even read an SF novel in which a ship travels faster than light by accellerating a normal mass beyond the speed of light while keeping that mass within normal spacetime, and I've read hundreds of science fiction novels.
One could make a case for Vernor Vinge's A Fire Upon The Deep. The objection that the Beyond isn't normal spacetime is easily answered with a simple "how do you know?"
This is, of course, the larger question. The lightspeed limit is still based on a surprisingly large amount of speculation. No one has ever directly observed anything like a Kg of mass accelerated to 0.98c. Maybe our extrapolations from high-velocity nanomasses and high-mass nanovelocities don't hold for large masses at high velocity? Heaven knows that classical mechanics got thoroughly corrected for nanoscales and high velocities when we were finally able to observe these phenomena "directly".
So why are SF writers so wormhole-obsessed? I say just declare 21st-century physicists wrong about the whole FTL thing, and move on.
Good idea. In fact, such a good idea that they already do.
So I asked, "What's the problem?" She replied, "I can't tell you. I don't even know you..." I said, "Well sometimes it's good to tell your problems to a perfect stranger on a bus." ---Steven Wright
Where's a Red-level Troubleshooter when you need one?
Uh, no. A little math, assuming a constant 3.1% annual inflation rate, shows that there were 14 $100M (1970 dollars) grossing films in the 70s, 13 in the 80s, and 8 from 1990-1995. So statistically, inflation really does predict the whole story.
I wanted to clear up the notion that poker comes down to chance, when there is very solid mathematical theory behind it.
The classic book on this subject is by David Sklansky. Highly recommended.
Uh, a US letter currently doesn't have to have a return address, much less a validated one. And a public mailbox in a big US city is pretty darn anonymizing. After all, they still haven't caught the folks who sent anthrax-filled letters to US government officials---and I'm guessing it's not for want of trying.
You should be suspicious of this rationale, since it is ridiculous if carried to the extreme. Books and chalkboards, after all, are only "technological crutches" for learning, as are heated and air-conditioned classrooms with artificial light.
The bottom line is that something like 80% of the expenses at a typical American high school or college are salaries. If you can spend $2000 on anything that makes a classroom teacher being paid $30000/year even slightly more productive, you've probably won. After all, it only takes a 2% productivity gain over 3 years to break even.
Does this same logic make it stupid not to maintain and improve buildings? You bet: arguably even more so. But it's not an intuitive tradeoff to most people for some reason, even though the math is quite easy to understand. I think a lot of it is simple, if misguided, inherency. "If charcoal on the back of a wooden shovel was good enough for Abe Lincoln, it's good enough for my kid."
How is this insightful? I'm a Ph.D. computer scientist with more than 20 years computing experience in a variety of areas. I have a long list of employers who will talk glowingly about my problem-solving skills. If RIM or Google or Microsoft or whoever tried to give me a puzzle-solving test in a job interview at this point in my career, I'd walk out.
One of my closest friends walked out of Sequent on this basis some years ago. He's now one of the most successful (and employable) computer people in the industry. As for Sequent...dead dead dead. Speaking of which, how is RIM doing these days?
Puzzle-solving tests in interviews may be appropriate for folks who haven't already solidly demonstrated their problem-solving skills in their application domain in some other way. For the rest of us, IMHO it's really a bit insulting; on the order of a hazing exercise. A certain class of manager will predictably reject folks who are unwilling to be hazed. I don't have much interest in working for those folks.
We're pretty far off topic. That said...
Future Shop is certainly not Fry's. I agree that FS's prices are usually poor and their sales tactics sometimes questionable. But in our town they aren't the competition for the small shops: Fry's is.
Yes, in my area the small shops are indeed the ex-furniture-dealer types :-). It sounds to me like your shop is exceptional. This is great, and I wish you all the best!
More expensive by what... $5/hard drive? $20/computer?
In my experience, small-shop hardware prices run typically about 50% more than Fry's, which means 60-70% more than bottom-dollar web merchants. And they typically stock 0.1-0.01 times the selection of Fry's. Thus, whenever I go in there, it's not likely they have what I want, and when they do it's priced so outrageously I leave anyway. Doesn't take much of that kind of reinforcement to keep me away.
I believe it could be better. Small computer+electronics merchants need to learn the virtues of broad+shallow inventories and better inventory targeting. They need to understand how to better use sale pricing as a promotional tool and to turn over inventory. They need to market to their local customers. They need to be open at the kind of hours folks actually shop for this stuff. All of these are things that have made Fry's successful in our area, and that small merchants can easily do. Then I'll try more often to buy something from them.
There's a move afoot to restrict the sale of high-bandwidth analog-to-digital and digital-to-analog converters in the US, since they are used by open software-defined radio (SDR) manufacturers to produce hardware that could easily circumvent the broadcast flag. This is scary and ridiculous at the same time: I'm not sure whether to hope the restriction fails (and ubiquitous SDR solves the broadcast flag problem) or succeeds (and the US becomes an noncompetitive joke in a whole range of industries, providing a valuable object lesson). No, wait---I'll take the first thing.
Offtopic: why does slashcode elide so many HTML entities, including — ? It's really annoying, and seems totally gratuitous to me.
Yep. Ability to ring the phone would be a key difference between the tiny $20 generic POTS product and the largish-looking $60 apparently-skype-only product :-) :-).
The only disadvantage is that it's not like a real phone, it won't ring if someone calls you.
That's because a real US POTS line uses a 90VAC ring "signal" (actually provides power for an old mechanical ringer if you have one) and there are a lot of good reasons the Chatcord folks wouldn't want to generate that. Too bad, though.
The odd thing about the Scooba is that iRobot's first product was also a floor-cleaning machine. I've heard Rod Brooks tell this story in person a couple of times, and it cracked me up.
PC Magazine, for example, says:
If you read between the lines here, you get the real story: they spent a lot of time building this three-function janitor-bot with a big computer in the middle to drive it around the building. They then started showing it to potential customers, every one of whom said the same thing: "A 3-function cleaning machine? That's fantastic! Take that computer out of the middle of it and put a handle on for the janitor and we'll buy a bajillion of 'em!"
So they did. The hole where the computer had been made nice storage. Better yet, iRobot had learned a valuable lesson about disruptive technologies: small steps.
No, the one who gets me is Yoda. May I take the opportunity to enter a brief plea in favor of his extermination?
But of course. Yoda is evil!
Parent wrote " My `public interest' would be nicely served by actually being able to get broadband. And I have power lines."
Which is why this stupid idea is so seductive. Everybody wants broadband, everybody has power lines. What's the problem?
(1) It doesn't work, and really can't work. (2) It has bad negative consequences for other systems (forget ham radio, and consider the emergency radio bands it overlaps). (3) Even if it did work, it would be more expensive and less available than current broadband channels.
I mean, everybody who wants broadband probably has water pipes, too. Why not broadband over tapwater? Pulse-modulate the chlorine and fluorine levels in the pipes, and read the bits right off there... BPL isn't much more sensible than BT when you look at it closely.
Nope. Read your GPL carefully. If func_mine_all_mine() is part of a GPL-ed program, you'll have to release its source anytime you release the binary to that program.
Now there's some controversy about what counts as "part of a GPL-ed program." Shared libraries? Kernel modules? Driver scripts? RMS and the FSF legal team, Linus Torvalds, and others have all released opinions on this, but so far I'm not aware of any court cases that have defined these limits legally. It may be that DN's lawyers think that they have a legal case for keeping some code out.