This is also why so many applications are now designed for the web. In effect, it takes care of the portability layer. For the cases where you really only want something like a "temperature converter GUI" it seems like an ideal solution.
It's such a compelling solution for these cases that I think the industry tends to want to shoehorn all applications into this form. And I find nothing more pathetic than the misapplication of a perfectly good idea to the wrong problem.
You can build your program on top of a layer of your own that serves as an interface with whatever API is needed.
The idea being that all of the portability issues will be confined to the interface layer. Moving to a different platform, or even tracking changes to an existing platform, should then have no effect on the majority of program code, since it lies outside of this layer.
That's the theory. In practice the effort required can vary a lot from one application to another. The easiest cases are operations which are to be expressed have fairly conventional meaning, for example getting a list of network interfaces from the system. Conversely, the most challenging cases involve fundamentally dissimilar models or capabilities, or else semantic complexity and context that has to be carried around.
The strategy for the first alternative, if you're committed to portability, is to restrict your design to a modest set of platform capabilities. That's always a good design discipline anyway, so I think you actually come out ahead if you think in terms of portability for any design project, excepting perhaps proofs of concept and other transient projects.
The second alternative is the really expensive one, since what you're really doing in the interface layer is building some kind of elaborate context management system on top of some other elaborate context management system. And I think this illustrates the point being made by the parent in saying you have to be expecting the contexts you want to support.
How exactly is information a "non-rival" good?... Sharing unrestricted info has legal implications right?
Remember that we're talking about economic theory here. As with any theory, it's based on a set of formal definitions. You can consult any introductory textbook for coverage in depth. The article gives a short, intuitive definition for "non-rival good" by suggesting that,
"Your use of it does not interfere with my use."
A textbook would go to greater length, for example pointing out that a definition such as this concerns inherent properties of a thing in economic terms.
It's obvious that legal effects, on the other hand, are not inherently associated with goods at all. The legal system, first of all, has a completely different theoretical basis, and second, is related primarily to actions, not things.
With those points in mind, let's look at what happens when information is shared. The actual information which I possess is inherently the same, whether or not you also possess it. Got that? So economic theory classifies it as a "non-rivalrous good".
Of course there could be consequences to me in your knowing this information, but that attaches to what you do with it, not to the information itself. What your actions then signify in law depend on a particular body of law, without reference to which the discussion has no meaning. So for example we would have to decide whether to talk about specific US copyright law as enacted in 2005, the traditions of English common law which began circa 1066, or Socratic notions of civil law circa 400 BCE.
But I think you caught the same error that I did. Converting to spread-spectrum doesn't produce a "non-rivalrous" good from a rivalrous one. It produces a rivalrous good from what was once an exclusive good.
No, Gates is not even telling the truth under this narrow and charitable interpretation. It wouldn't make interoperability a lot easier, because there would be nothing besides Microsoft with which to interoperate. Pardon me for adding clarification and emphasis to your comments.
Why is true interoperability important? For security, something else that Bill Gates manifestly doesn't understand, except in purely narcissistic terms perhaps. Security for Microsoft consistently means whatever is good for Microsoft.
Security for you and me means, among other things, not being held hostage to a single supplier, in case its product has security shortcomings. And that means being able to rapidly substitute products from other suppliers.
And that means an environment which permits true interoperability, a concept to which Microsoft is strategically opposed. Your quote from Bill Gates demonstrates just how pervasive this thinking really is. As the IETF has long recognized, multiple implementations are the only proof that a design is truly interoperable. As you say, it's worth it so people can have choice.
But Linux isn't particularly designed for Intel processors. In fact, it's probably the most multiplatform operating system in existence.
So if Intel had faltered, it seems very likely that Linux development would simply have continued on whatever processor(s) happened to be cheap and available.
Your point about Microsoft stimulating Intel development is valid, though, and the combined displacement effect on the industry has been massive. Without that displacement, we'd be looking at a very different ecosystem. Perhaps it would be dominated by some other architecture, or perhaps it would have produced diverse players, more cooperation on interoperability, and more competition on engineering merit. Perhaps every little gadget today would be based on multicore RISC, who knows?
to chain together many small commands to accomplish a single task very easily. I suspect there is some terminology for this process, but as I don't know what it is
You're on to something here. The essential design principle is composability. Take Lego for example. You can make complex artifacts by assembling many existing elements together.
A similar, but distinct, principle is extensibility. To continue with the Lego example, it allows you to invent a completely new element that extends the behavior of existing elements, a slider piece for example.
Not to get totally pedantic, but let's have one more. The principle of modularity enables both of the above. Originally, it meant that you could replace any piece with a functionally identical substitute. But what makes it such an interesting principle is that there are different aspects of identity. Two 1x8 Legos might be replaced by a 2x4 and two 2x2s, and so on, and perhaps the substitution has different and desirable properties.
The source of all modularity is the enabling principle of standardization. And here, if you care, is where open source comes into the picture. Because it's very hard for multiple parties to ever agree on a common standard if the candidate designs are all secret!
So your intuition is right. There is something about Unix that gives it a fundamental advantage over proprietary alternatives. However, to debate between command line and GUI, or likewise to compare statistics on security incidents, is to focus on emergent symptoms. I get frustrated with these debates because they never really seem to converge on a clear answer.
A clear answer does emerge when we look to deeper principles. These aren't just a matter of subjective preference, they are fundamental to the design of any complex artifact. Designs which express these principles are objectively superior to designs which don't. And I think that's worth remembering.
I heard an insightful program on CBC Radio a few months ago which drew a comparison between the present American Empire and past British and Roman empires.
One factor in common to all these empires is that their citizens at the time generally didn't perceive themselves as being part of an empire! The effect doesn't necessarily require a campaign of disinformation, in other words. Though it helps further the effect.
Being a Canadian, I get to watch the workings of the American Empire from a ringside seat. It's both heartbreaking and encouraging. The very fact that we can have this discussion is fantastic. There is room in American culture for both diversity and an extremely generous spirit of inquiry. But at the same time, there seem to be some very strange limits to that inquiry, one in particular being any reference to empire and its damaging effects on nationhood and culture, another being genuine confusion at any news that the world doesn't welcome the imposition of empire.
Of course it's easy to see the US Administration as the bad guys, not truly representative of the American people. But there is a sociological dimension underneath this as well, which is what makes it possible. In that sense this Administration is representative of American values, and that, from an outside perspective at least, is the truly scary dimension of this particular global empire.
A realistic total cost of ownership takes into account the capital and operating costs over the total lifetime of the computing environment.
Over that lifetime you're going to see several cycles of hardware and software. One clear principle which emerges through this experience is that you absolutely must keep your options open, meaning that the real TCO focus has to be on interoperability. The alternative leaves you locked into a solution which depends on a single vendor.
Design your systems so that they can be ported easily from one platform to another, because if you're lucky they will be. If you're not lucky, your fortunes will be tied to the one vendor, and that's not a pretty place to be.
Different sites have differing conventions about where software should be installed. I'm surprised at how many people seem to have no conception of what it's like to run on anything other than a standalone system.
Sure, on a system like that, it may make sense to install software in/usr/local, and have home directories in/home. But remember that those conventions are nominal at best. The real world is a lot more varied, because it has to be.
It is! I recognize it for sure.
It turns out that there is no paper, but there are some very readable slides.
John Ousterhout is the author, and that makes total sense in retrospect. He developed Tcl/Tk, which emphasizes events. Actually, the event mechanism itself was migrated from Tk to Tcl only a few years ago.
Thank you!!!
So I'll list some "soft" indicators of when you shouldn't use threads
When event dispatch is sufficient.
I came across a paper about five years ago which I thought argued this point quite eloquently, basically reminding people that lots of problems don't require true concurrency. I've lost track of it now, but I'd be delighted if someone remembers it.
I have to agree. The grandparent is wildly misleading and should probably be disregarded completely.
Here are a couple of points in addition to the parent:
Computer systems and their components are manufactured to published specifications, which typically include minimum and maximum operating temperature and non-operating temperature. It is safe to believe these specifications. It is not safe to ignore them.
We all know that components can be damaged by excessive heat. Less obvious is that they can also suffer permanent damage from excessive cold. Mechanical devices and circuit boards are always sensitive to thermal stress, but especially so when their materials are cold and brittle. You only need to break one trace to ruin a board.
I sort of agree with you, in the sense that people should know better than to indulge irresponsible behavior.
But I think there might be some legitimate confusion about what behavior is in fact irresponsible and risky. Not long ago, we discovered that the tobacco industry had deliberately targeted children in order to secure a demand for its products. Before that, it had told adults that smoking was beneficial for their health.
People are born with some instincts about risk in the natural world, but we're not born knowing anything about technological risk, much less when that risk has been deliberately disguised by those who seek to profit from our disadvantage.
Much of marketing is about misleading people. People like you and I may have some natural skill at defending against it, and that's great for us, but we are not the low-hanging fruit against which the marketing effort is generally directed. The urban SUV driver who cuts me off while talking on his cell phone: his selfish attitude is ripe to be targeted. And if he spoils his kids and then has to pay for their SMS bills, I'm not going to feel sorry for him. On the other hand, I think that some elderly couple who have taken a cell subscription in good faith are also ripe to be targeted, as are their grandchildren who are not yet developmentally ready for critical thought, as are the parents who are overwhelmed as never before by the modern complexities of work and parenting.
Therefore, I think it's not enough to say that all these people simply need to become less indulgent and more responsible. If we were dealing with the hazards of the natural world, I would have to agree with you, and let natural selection play itself out. But we're talking about forms of exploitation which are deliberately made to (a) take advantage of human weakness, and at the same time (b) fly under the legal radar.
We have to try to teach our kids to defend against all of this really nasty stuff without making cynics of them, and without alienating them from their less critical peers. That's not easy.
Here's the thing. When you decide to put together a demo, you decide what it is that you want to present, and how to present it. Nobody is holding a gun to your head.
As Mark Knopfler wrote, "When you point your finger cause your plan fell through, there's three more fingers, pointing back at you."
Plus, the CBC is not the State by any stretch of the imagination. It's a bunch of people who, as it happens, are working in a sector of broadcast media that has been legislatively granted a degree of creative independence. CBC Television is a bit ponderous because it has to worry about advertizing revenue, whereas CBC Radio has a longer, and in my view more successful, tradition of media independence.
CBC people make an extraordinary effort to be part of the Canadian community, showing up at public events and giving them welcome support and visibility. Arguably, that's part of the CBC mandate, but when I look at the hours and conditions required to make this effort, I think it goes well beyond the job description.
I listen to CBC Radio and I like what I hear. Sometimes the content is boring, sometimes enlightening, but always civil and thoughtful. In short, these are people who reflect my values as a Canadian.
In that regard, how is "mainstream" possibly close to describing Linux?
He seems to be talking exclusively about "mainstream" in the IT world.
It's a good question, and you've supplied the answer. You're right to say that the answer depends on context, and the context here seems to involve the traditional computing industry rather than personal computing.
Looking at the article, I see zero references to "home", "personal", "consumer", or even "small business". Curiously, there is no mention of embedded systems. On the other hand, the word "server" appears four times, and "client" three times.
Given that context, and understanding that eWeek is a trade magazine for the computing industry, the article seems to make some reasonable observations about mainstream computing. But if you were expecting an article on consumer systems, I can see why you might be bothered.
What was it that drew you to a life of programming? How old were you when you first used a computer?
For me, it was a bundle of punched cards and some pages of a FORTRAN program listing. It arrived in the mail in a small blue box, one of a series of boxes that I regularly received as part of a subscription called Things of Science around 1967 or so.
Though I was too impatient at the time to sit down and really try to understand how this kind of notation could express some desired behavior, I know that something important clicked for me at that moment. Computers were suddenly tangible things, and their mysteries perhaps not so impenetrable as the popular media of the day had led us to believe.
By 1969 I had managed to get a tour of an actual computer. I don't think I got to submit a batch program until around 1972, and that was in BASIC on punched cards. I was absolutely thrilled to get my first printout delivered to me a day later, even though it almost certainly said little more than SYNTAX ERROR.
I'm mentioning these details because I want to suggest just how compelling the act of programming can be to a curious young mind, even in the absence of a rich development environment. Indeed, one can argue that exposure, simplicity, and rapid feedback are the really critical conditions to encourage programming, while the rest is largely cosmetic.
Of course, expectations are very different now than they were thirty years ago, and it may be harder now to capture the attention of an overstimulated, oversupervised child than it was when a transistor radio was the pinnacle of excitement at Christmastime. But human intellectual capacity has not changed, nor has the nature of algorithmic design. Encourage kids who show an interest in programming, and let their curiosity take care of the rest.
Linux was designed from the beginning as a multiuser environment with appropriate protection given to the operating system. Windows was designed for use on standalone systems where whoever was at the console would have unrestricted access to the entire system.
So, Windows users may feel some frustration when your site moves to Linux, but any damage they do is strictly limited to themselves. And if some users prove truly inept, you can always set their accounts to run a limited set of applications, or indeed anything else you choose to meet your requirements.
Windows is like one of those elaborate but boring toys which you can only use for passive kinds of play. Linux and Unix are designed to be used like Lego. You're supposed to take the pieces and use them to create something. This does require a somewhat different mindset, and has different implications.
One consequence is the insight that a discussion concerning you the designer can imply a different person with not just different privileges but a different environment than you the user.
That tax money depends on a robust economy that is in large part driven by 'closed knowledge.'
It's an interesting argument, but it presumes a zero-sum game in which all wealth is finite. Certain forms of wealth are finite, but many are at least elastic, and others, particularly concepts and methods, are not intrinsically bounded forms of wealth at all.
It's difficult therefore to infer that science would not exist without external funding. Historically, this has not been so. It seems to me that science exists whenever people take an interest in some phenomenon, and that seems very much in the nature of what it is to be human.
From that perspective, it seems really bizarre to go around trying to capture the wealth of ideas, as if there were not enough to go around, or as if sharing an idea would somehow diminish its value. On the contrary, sharing an idea is more likely to enrich the field of ideas. Closing knowledge, on the other hand, is just another way to fence off a piece of the commons for personal gain.
Correct. Of course, he has to be vague, because what specific proposal can he offer?
For that matter, who would agree with his characterization of the Internet security problem in the first place? Most of us know that security has to be established between endpoints, not in the connection itself. Tenet comes from the old school that saw the threat and the solution being on the wire. So as you say, what are we going to do now, put the entire planet inside a hardened cable vault?
I am in favor of licensing Internet access in the same way we have come to license the use of motor vehicles on public roads. Such measures won't entirely stop the carnage, but at least they provide a handle on the human factors of security: awareness and liability.
Slashdot Mirror
It's such a compelling solution for these cases that I think the industry tends to want to shoehorn all applications into this form. And I find nothing more pathetic than the misapplication of a perfectly good idea to the wrong problem.
The idea being that all of the portability issues will be confined to the interface layer. Moving to a different platform, or even tracking changes to an existing platform, should then have no effect on the majority of program code, since it lies outside of this layer.
That's the theory. In practice the effort required can vary a lot from one application to another. The easiest cases are operations which are to be expressed have fairly conventional meaning, for example getting a list of network interfaces from the system. Conversely, the most challenging cases involve fundamentally dissimilar models or capabilities, or else semantic complexity and context that has to be carried around.
The strategy for the first alternative, if you're committed to portability, is to restrict your design to a modest set of platform capabilities. That's always a good design discipline anyway, so I think you actually come out ahead if you think in terms of portability for any design project, excepting perhaps proofs of concept and other transient projects.
The second alternative is the really expensive one, since what you're really doing in the interface layer is building some kind of elaborate context management system on top of some other elaborate context management system. And I think this illustrates the point being made by the parent in saying you have to be expecting the contexts you want to support.
Why bother when there's so much other low-hanging fruit to pick from?
Remember that we're talking about economic theory here. As with any theory, it's based on a set of formal definitions. You can consult any introductory textbook for coverage in depth. The article gives a short, intuitive definition for "non-rival good" by suggesting that, "Your use of it does not interfere with my use."
A textbook would go to greater length, for example pointing out that a definition such as this concerns inherent properties of a thing in economic terms.
It's obvious that legal effects, on the other hand, are not inherently associated with goods at all. The legal system, first of all, has a completely different theoretical basis, and second, is related primarily to actions, not things.
With those points in mind, let's look at what happens when information is shared. The actual information which I possess is inherently the same, whether or not you also possess it. Got that? So economic theory classifies it as a "non-rivalrous good".
Of course there could be consequences to me in your knowing this information, but that attaches to what you do with it, not to the information itself. What your actions then signify in law depend on a particular body of law, without reference to which the discussion has no meaning. So for example we would have to decide whether to talk about specific US copyright law as enacted in 2005, the traditions of English common law which began circa 1066, or Socratic notions of civil law circa 400 BCE.
But I think you caught the same error that I did. Converting to spread-spectrum doesn't produce a "non-rivalrous" good from a rivalrous one. It produces a rivalrous good from what was once an exclusive good.
Why is true interoperability important? For security, something else that Bill Gates manifestly doesn't understand, except in purely narcissistic terms perhaps. Security for Microsoft consistently means whatever is good for Microsoft.
Security for you and me means, among other things, not being held hostage to a single supplier, in case its product has security shortcomings. And that means being able to rapidly substitute products from other suppliers.
And that means an environment which permits true interoperability, a concept to which Microsoft is strategically opposed. Your quote from Bill Gates demonstrates just how pervasive this thinking really is. As the IETF has long recognized, multiple implementations are the only proof that a design is truly interoperable. As you say, it's worth it so people can have choice.
So if Intel had faltered, it seems very likely that Linux development would simply have continued on whatever processor(s) happened to be cheap and available.
Your point about Microsoft stimulating Intel development is valid, though, and the combined displacement effect on the industry has been massive. Without that displacement, we'd be looking at a very different ecosystem. Perhaps it would be dominated by some other architecture, or perhaps it would have produced diverse players, more cooperation on interoperability, and more competition on engineering merit. Perhaps every little gadget today would be based on multicore RISC, who knows?
You're on to something here. The essential design principle is composability. Take Lego for example. You can make complex artifacts by assembling many existing elements together.
A similar, but distinct, principle is extensibility. To continue with the Lego example, it allows you to invent a completely new element that extends the behavior of existing elements, a slider piece for example.
Not to get totally pedantic, but let's have one more. The principle of modularity enables both of the above. Originally, it meant that you could replace any piece with a functionally identical substitute. But what makes it such an interesting principle is that there are different aspects of identity. Two 1x8 Legos might be replaced by a 2x4 and two 2x2s, and so on, and perhaps the substitution has different and desirable properties.
The source of all modularity is the enabling principle of standardization. And here, if you care, is where open source comes into the picture. Because it's very hard for multiple parties to ever agree on a common standard if the candidate designs are all secret!
So your intuition is right. There is something about Unix that gives it a fundamental advantage over proprietary alternatives. However, to debate between command line and GUI, or likewise to compare statistics on security incidents, is to focus on emergent symptoms. I get frustrated with these debates because they never really seem to converge on a clear answer.
A clear answer does emerge when we look to deeper principles. These aren't just a matter of subjective preference, they are fundamental to the design of any complex artifact. Designs which express these principles are objectively superior to designs which don't. And I think that's worth remembering.
Exactly. That's what's being recommended here in Canada.
One factor in common to all these empires is that their citizens at the time generally didn't perceive themselves as being part of an empire! The effect doesn't necessarily require a campaign of disinformation, in other words. Though it helps further the effect.
Being a Canadian, I get to watch the workings of the American Empire from a ringside seat. It's both heartbreaking and encouraging. The very fact that we can have this discussion is fantastic. There is room in American culture for both diversity and an extremely generous spirit of inquiry. But at the same time, there seem to be some very strange limits to that inquiry, one in particular being any reference to empire and its damaging effects on nationhood and culture, another being genuine confusion at any news that the world doesn't welcome the imposition of empire.
Of course it's easy to see the US Administration as the bad guys, not truly representative of the American people. But there is a sociological dimension underneath this as well, which is what makes it possible. In that sense this Administration is representative of American values, and that, from an outside perspective at least, is the truly scary dimension of this particular global empire.
A realistic total cost of ownership takes into account the capital and operating costs over the total lifetime of the computing environment.
Over that lifetime you're going to see several cycles of hardware and software. One clear principle which emerges through this experience is that you absolutely must keep your options open, meaning that the real TCO focus has to be on interoperability. The alternative leaves you locked into a solution which depends on a single vendor.
Design your systems so that they can be ported easily from one platform to another, because if you're lucky they will be. If you're not lucky, your fortunes will be tied to the one vendor, and that's not a pretty place to be.
Different sites have differing conventions about where software should be installed. I'm surprised at how many people seem to have no conception of what it's like to run on anything other than a standalone system.
Sure, on a system like that, it may make sense to install software in /usr/local, and have home directories in /home. But remember that those conventions are nominal at best. The real world is a lot more varied, because it has to be.
It is! I recognize it for sure. It turns out that there is no paper, but there are some very readable slides. John Ousterhout is the author, and that makes total sense in retrospect. He developed Tcl/Tk, which emphasizes events. Actually, the event mechanism itself was migrated from Tk to Tcl only a few years ago. Thank you!!!
-
When event dispatch is sufficient.
I came across a paper about five years ago which I thought argued this point quite eloquently, basically reminding people that lots of problems don't require true concurrency. I've lost track of it now, but I'd be delighted if someone remembers it.Hey, you spelled "powerfull" right!
Hey, you spelled "powerfull" wrong!
Here are a couple of points in addition to the parent:
Computer systems and their components are manufactured to published specifications, which typically include minimum and maximum operating temperature and non-operating temperature. It is safe to believe these specifications. It is not safe to ignore them.
We all know that components can be damaged by excessive heat. Less obvious is that they can also suffer permanent damage from excessive cold. Mechanical devices and circuit boards are always sensitive to thermal stress, but especially so when their materials are cold and brittle. You only need to break one trace to ruin a board.
But I think there might be some legitimate confusion about what behavior is in fact irresponsible and risky. Not long ago, we discovered that the tobacco industry had deliberately targeted children in order to secure a demand for its products. Before that, it had told adults that smoking was beneficial for their health.
People are born with some instincts about risk in the natural world, but we're not born knowing anything about technological risk, much less when that risk has been deliberately disguised by those who seek to profit from our disadvantage.
Much of marketing is about misleading people. People like you and I may have some natural skill at defending against it, and that's great for us, but we are not the low-hanging fruit against which the marketing effort is generally directed. The urban SUV driver who cuts me off while talking on his cell phone: his selfish attitude is ripe to be targeted. And if he spoils his kids and then has to pay for their SMS bills, I'm not going to feel sorry for him. On the other hand, I think that some elderly couple who have taken a cell subscription in good faith are also ripe to be targeted, as are their grandchildren who are not yet developmentally ready for critical thought, as are the parents who are overwhelmed as never before by the modern complexities of work and parenting.
Therefore, I think it's not enough to say that all these people simply need to become less indulgent and more responsible. If we were dealing with the hazards of the natural world, I would have to agree with you, and let natural selection play itself out. But we're talking about forms of exploitation which are deliberately made to (a) take advantage of human weakness, and at the same time (b) fly under the legal radar.
We have to try to teach our kids to defend against all of this really nasty stuff without making cynics of them, and without alienating them from their less critical peers. That's not easy.
As Mark Knopfler wrote, "When you point your finger cause your plan fell through, there's three more fingers, pointing back at you."
Plus, the CBC is not the State by any stretch of the imagination. It's a bunch of people who, as it happens, are working in a sector of broadcast media that has been legislatively granted a degree of creative independence. CBC Television is a bit ponderous because it has to worry about advertizing revenue, whereas CBC Radio has a longer, and in my view more successful, tradition of media independence.
CBC people make an extraordinary effort to be part of the Canadian community, showing up at public events and giving them welcome support and visibility. Arguably, that's part of the CBC mandate, but when I look at the hours and conditions required to make this effort, I think it goes well beyond the job description.
I listen to CBC Radio and I like what I hear. Sometimes the content is boring, sometimes enlightening, but always civil and thoughtful. In short, these are people who reflect my values as a Canadian.
It's a good question, and you've supplied the answer. You're right to say that the answer depends on context, and the context here seems to involve the traditional computing industry rather than personal computing.
Looking at the article, I see zero references to "home", "personal", "consumer", or even "small business". Curiously, there is no mention of embedded systems. On the other hand, the word "server" appears four times, and "client" three times.
Given that context, and understanding that eWeek is a trade magazine for the computing industry, the article seems to make some reasonable observations about mainstream computing. But if you were expecting an article on consumer systems, I can see why you might be bothered.
For me, it was a bundle of punched cards and some pages of a FORTRAN program listing. It arrived in the mail in a small blue box, one of a series of boxes that I regularly received as part of a subscription called Things of Science around 1967 or so.
Though I was too impatient at the time to sit down and really try to understand how this kind of notation could express some desired behavior, I know that something important clicked for me at that moment. Computers were suddenly tangible things, and their mysteries perhaps not so impenetrable as the popular media of the day had led us to believe. By 1969 I had managed to get a tour of an actual computer. I don't think I got to submit a batch program until around 1972, and that was in BASIC on punched cards. I was absolutely thrilled to get my first printout delivered to me a day later, even though it almost certainly said little more than SYNTAX ERROR.
I'm mentioning these details because I want to suggest just how compelling the act of programming can be to a curious young mind, even in the absence of a rich development environment. Indeed, one can argue that exposure, simplicity, and rapid feedback are the really critical conditions to encourage programming, while the rest is largely cosmetic.
Of course, expectations are very different now than they were thirty years ago, and it may be harder now to capture the attention of an overstimulated, oversupervised child than it was when a transistor radio was the pinnacle of excitement at Christmastime. But human intellectual capacity has not changed, nor has the nature of algorithmic design. Encourage kids who show an interest in programming, and let their curiosity take care of the rest.
So, Windows users may feel some frustration when your site moves to Linux, but any damage they do is strictly limited to themselves. And if some users prove truly inept, you can always set their accounts to run a limited set of applications, or indeed anything else you choose to meet your requirements.
Windows is like one of those elaborate but boring toys which you can only use for passive kinds of play. Linux and Unix are designed to be used like Lego. You're supposed to take the pieces and use them to create something. This does require a somewhat different mindset, and has different implications.
One consequence is the insight that a discussion concerning you the designer can imply a different person with not just different privileges but a different environment than you the user.
It's an interesting argument, but it presumes a zero-sum game in which all wealth is finite. Certain forms of wealth are finite, but many are at least elastic, and others, particularly concepts and methods, are not intrinsically bounded forms of wealth at all.
It's difficult therefore to infer that science would not exist without external funding. Historically, this has not been so. It seems to me that science exists whenever people take an interest in some phenomenon, and that seems very much in the nature of what it is to be human.
From that perspective, it seems really bizarre to go around trying to capture the wealth of ideas, as if there were not enough to go around, or as if sharing an idea would somehow diminish its value. On the contrary, sharing an idea is more likely to enrich the field of ideas. Closing knowledge, on the other hand, is just another way to fence off a piece of the commons for personal gain.
Correct. Of course, he has to be vague, because what specific proposal can he offer? For that matter, who would agree with his characterization of the Internet security problem in the first place? Most of us know that security has to be established between endpoints, not in the connection itself. Tenet comes from the old school that saw the threat and the solution being on the wire. So as you say, what are we going to do now, put the entire planet inside a hardened cable vault? I am in favor of licensing Internet access in the same way we have come to license the use of motor vehicles on public roads. Such measures won't entirely stop the carnage, but at least they provide a handle on the human factors of security: awareness and liability.