Aside from the graphical approach to programming, this sounds a lot like existing languages such as occam (which has the additional advantage of being formally rooted in Hoare's CSP). Not exactly "revolutionary".
Don't get me wrong, I really like the signal-based model. But in my experience many systems are more clearly and easily expressed in an applicative or state-based style. I'd rather have the ability to apply higher-order techniques, state, and signals, as appropriate.
I won't bother to get into my objections to "graphical programming" here. But suffice it to say that I believe there are a number of problems with the concept.
As an aside: I suggest that you spend some time looking into concurrency theories such as CSP, CCS, and the pi-calculus. They elegantly (and mathematically) capture the notion of "connecting elementary objects (cells) together... into high-level, plug-compatible components and/or applications...". These theories have been udner continuous development for 20+ years, and provide a great way to reason about and understand the kind of systems you want to build with COSA.
AFAIK, the Atlas V has little in common with the original Atlas ICBMs, aside from the name.
Re:Stallman was right up to this point ...
on
Textbooks With EULAs
·
· Score: 2, Informative
What surprises me most, really, is that I have never come across a repository of free textbooks available in some standard electronic form - say PDF.
You mean like this, or this? Those are just the two I happen to have bookmarked. I'm pretty sure there're a few more out there. Admittedly, not everything they link to is in PDF format, but a lot of it is.
There is more to InfoSec than cryptography. Crytography may not involve axiomatic set theory. Secure systems programming does. Formal verification of security protocols is often conducted using either theorem-provers rooted in higher-order logic, or using model-checkers that make use of process algebras or temporal logics. A good understanding of things like modern abstract algebra and modern set theory, while not crucial to using these tools, can help immeasurably. I've only dabbled in the area of formal protocol analysis, and even that left me wishing I was better versed in higher math than I am.
But much of your "private" information could be used to conduct statistical studies that might "contribute to the sum of human knowledge" in all sorts of ways.
Information is information. Period. If you want something to be a secret, keep it secret. If you want to share information, but impose certain conditions on its use, you are entering a trust relationship where you assume that the recipient of your information will use it only as you wish. If they break the "contract" on their use of the information you provided them you may be able to seek recourse under the law (copyright law, privacy law, etc) - which is essntially a way of codifying and attempting to enforce some trust relationships. But otherwise your only recourse is simply to point out to everyone else that your trust was broken - there's no way to unshare your information. Anyone dealing in information will face this problem, be they the RIAA, MPAA, FSF, or a private individual.
Please do not talk about engineering if you do not know what it is. There are many engineering projects that involve building unprecedented systems (bridge-building for starters, since no two bridge locations are the same - the reuse of bridge design principles is more akin to code reuse, or better yet algorithm reuse). And don't be fooled by what passes for "engineering" education in most software "engineering" classes - it is emphatically not engineering. I suggest you look up some of David Parnas' writings on software engineering if you want to understand what software engineering should be if it is to deserve the name engineering.
They rather sya that if you did a good analysis, detailed specs, reviews, inspections and all those planification documents with a project manager behind them to make sure they're followed, code quality will be a natural result.
The sad thing is that real world experience (in either software dev or in "real" engineering) will teach you that this attitude is completely wrongheaded. Blindly following a process will not automatically lead to good results. The people who claim that are the ones that want to mechanize and commoditize engineering. Real engineering is a creative endeavour. Yes, it helps to have some guidelines and a framework for what kind of documentation you need to produce. But more important is to understand why you are producing that documentation, and how it helps you to reach your goal (which is to produce a good product). Too many people document "because we're supposed to", and, because the don't understand why they're doing it, they do a crappy job. The document is ultimately useless, but the appropriate process box has been checked, so everything's ok.
Real quality stems from having a commitment to producing a quality product, and creatively applying the tools available (analyses, documentation, test, etc) to ensure that your commitment is fulfilled. It doesn't come from blindly following step-by-step procedure: too often the result of that is a failed project, and a bunch of people standing around saying "it's not my fault - we followed the procedure!"
Bottom line: the SEI talks a good line, but they are severely detached from the real world (at least based on my own real-world experiences in several different fields of engineering).
Civil engineering isn't done that way either. I suggest that before you try to claim that software isn't engineering you first gain an understanding of what engineering is.
I think most of the people arguing about whether software development is "craft" or "engineering" have no idea what real engineering actually involves. Design is a creative process. Even engineering design.
Uh, have you ever actually done any engineering? It's as much a "craft" as software "engineering" is. Design is a fundamentally creative process. The difference between software "engineering" and "real" engineering is that real engineers have mathematical tools that allow them to analyze the designs that they have (creatively) developed, and to determine whether or not said designs will meet their requirements. Without having to go to the expense of a full-blown implementation. Such tools exist for software development too. They're just rarely used.
No, they needed tanks that light to make the design they selected work. Different design, different tank mass requirements. That's how spacecraft design works - every design choice affects other design choices.
I don't recall MD saying they'd need super-light tanks to get the Delta Clipper to work. Nor did Gary Hudson claim he needed super-light tanks for Phoenix, Roton, or any of his other designs. And as I mentioned before, Douglas Aircraft seemed to think the idea was feasible (both technically and economically) even with 60's technology.
That's funny. Douglas Aircraft Co thought it was feasible in the 60's. Gary Hudson has been working on SSTO since the 70's, and cites several efforts by other companies. Even NASA bought off on the idea when it started the X-33 program. They just botched it by picking a vaporware design that involved all sorts of innovations above and beyond SSTO. So why exactly are you claiming that SSTO "isn't feasible (yet)"?
Wait! So you're telling me that there are scalability problems with attempting to maintain centralized control of something? And that those scalability problems are related to cenrtalized controller becoming a throughput bottleneck? Who'd have thunk it?
Perhaps the USPTO needs to look into the patent filing equivalent of BitTorrent (quick, somebody patent that idea!)
And the answer seems to be some mixture of private and communal property, mediated via some level of democratic arbitration.
The problem arises in attempting to define what should be private and what should be communal. And more importantly, in defining who has effective control over "communal" property.
Individuals have a nasty habit of trying to assert "communal" control over putatively private property, simply because they object to how the current owners are using it. Those who maintain effective control over "communal" property have every reason to go along with this, since it increases the amount of stuff over which they have effective control. That is why we see a constant fight for the maintenance of "private property rights" in "legitimately democratic nations". That is why nations that formerly leaned more on the "private property" side of the private/communal line have slipped more towards the communal side (cf the recent US Supreme Court decision wrt eminent domain).
More to the point, just because a nation has adopted (through democratic means) some particular private/communal split, there's no reason that those who want more private property cannot campaign for it - what's the point of a democracy if the only "right" choices and opinions are those that lead to more communal control?
Property is a useful social construct. Nothing more, nothing less. Ignore the rules of a society, and property has no meaning.
The notion of private property has proven to be a useful social construct for eliminating "tragedy of the commons"-style misuse of resources, and for providing a framework that minimizes fighting over control of resources (if we both agree that "what's mine is mine and what's yours is yours", we won't fight over what to do with those resources - we can save out fights for other issues:-). Is private property required for liberty? Depends on how you define "liberty", doesn't it. The question is, what kind of "liberty" leads to a sustainable society that we'd all like to live in?
1. Observation and description of a phenomenon or group of phenomena.
Evolution and speciation has been observed (both in the fossil record and in the present day). These are the phenomena.
2. Formulation of an hypothesis to explain the phenomena. In physics, the hypothesis often takes the form of a causal mechanism or a mathematical relation.
Natural selection is the hypothesis to explain the observed phenomena.
3. Use of the hypothesis to predict the existence of other phenomena, or to predict quantitatively the results of new observations.
The natural selection hypothesis has been used to predict what kinds of new discoveries we should expect to find in the fossil record, and to predict how controlled breeding programs are likely to turn out.
4. Performance of experimental tests of the predictions by several independent experimenters and properly performed experiments.
Many paleontologists over the years have discovered new "intermediate" forms, as predicted by natural selection. Animal and plant breeders have been independently experimentally verifying the mechanism of selection ("artificial" in this case, but the principle is the same - any controlled experiment is necessarily "artificial") in the evolution of species for a very long time now.
As I said before: evolution, the phenomenon, is an observed fact. A theory of evolution is an attempt to explain the observed fact.
Err, that side of the moon isn't dark, so calling it the "dark side of the moon" is somewhat misleading. Perhaps you should have used the term "far side of the moon" instead.
Evolution is a fact. It has been observed in the fossil record, and observed in the present day. A "theory" of evolution seeks to explain how evolution occurs, i.e. the mechanism by which evolution takes place*. Darwin's theory of evolution was based on natural selection, and seems to be the accepted theory these days. Perhaps some day it will be discredited. But evolution will still exist.
*Note the parallels with gravitation: gravitational attraction between objects is a fact. Theories of gravitation seek to explain how that attraction works, thus allowing us to make predictions about how systems under the influence of gravity will evolve over time.
...there is too much of a chance that it would eventually get used for reducing more than just the harmful activities...
Oh, I'm sure that it would only ever get used to reduce or eliminate harmful activities. The problem lies in the definition of what constitutes "harmful activities". And who gets to make that definition.
TFA isn't really about CS. Mostly they seem to be talking about IT work, and perhaps some programming. Neither of which are really the guts of CS, even if they do get conflated with it on a regular basis. The article makes a big deal out of the fact that DeVry and Strayer are churning out lots of "CS" graduates compared to traditional CS programs. But both of those institutions provide vocational training, and quite clearly cater to a different market than the 4-year colleges. I don't know about Strayer, but DeVry (according to their website) doesn't even offer a "Computer Science" degree, just degrees in "Computer Engineering Technology" and "Computer Information Systems".
Can I just mention that I think the term "Cybersecurity" is stupid. Really, really stupid. really, really, really stupid. Actually, that goes for all the other Cyber- stuff that seems to pervade the internet these days too.
"Cyber" is derived from the Greek word for "pilot", or "controller". Norbert Wiener introduced the term into English when he started talking about "Cybernetics" - which was his term for complex feedback control systems (Cyber. Control systems. Kinda makes sense, huh?). How we morphed from Wiener's original usage to the current fad for prefixing "Cyber" onto some random word in order to make it seem computer-related (not even control-related!) is beyond me. Although I'm sure William Gibson deserves a pretty large portion of the blame.
I'm curious: why apply access controls on a per-folder rather than a per-file basis? Seems like the latter would be more flexible, since I may have several different types of files (with different access requirements) in a given directory (of course, since directories == files in Un*x the same would approach would apply to directories). Or is that the way SELinux works already (I have no experience with it)?
Slashdot Mirror
Don't get me wrong, I really like the signal-based model. But in my experience many systems are more clearly and easily expressed in an applicative or state-based style. I'd rather have the ability to apply higher-order techniques, state, and signals, as appropriate.
I won't bother to get into my objections to "graphical programming" here. But suffice it to say that I believe there are a number of problems with the concept.
As an aside: I suggest that you spend some time looking into concurrency theories such as CSP, CCS, and the pi-calculus. They elegantly (and mathematically) capture the notion of "connecting elementary objects (cells) together ... into high-level, plug-compatible components and/or applications...". These theories have been udner continuous development for 20+ years, and provide a great way to reason about and understand the kind of systems you want to build with COSA.
AFAIK, the Atlas V has little in common with the original Atlas ICBMs, aside from the name.
You mean like this, or this? Those are just the two I happen to have bookmarked. I'm pretty sure there're a few more out there. Admittedly, not everything they link to is in PDF format, but a lot of it is.
There is more to InfoSec than cryptography. Crytography may not involve axiomatic set theory. Secure systems programming does. Formal verification of security protocols is often conducted using either theorem-provers rooted in higher-order logic, or using model-checkers that make use of process algebras or temporal logics. A good understanding of things like modern abstract algebra and modern set theory, while not crucial to using these tools, can help immeasurably. I've only dabbled in the area of formal protocol analysis, and even that left me wishing I was better versed in higher math than I am.
Information is information. Period. If you want something to be a secret, keep it secret. If you want to share information, but impose certain conditions on its use, you are entering a trust relationship where you assume that the recipient of your information will use it only as you wish. If they break the "contract" on their use of the information you provided them you may be able to seek recourse under the law (copyright law, privacy law, etc) - which is essntially a way of codifying and attempting to enforce some trust relationships. But otherwise your only recourse is simply to point out to everyone else that your trust was broken - there's no way to unshare your information. Anyone dealing in information will face this problem, be they the RIAA, MPAA, FSF, or a private individual.
Please do not talk about engineering if you do not know what it is. There are many engineering projects that involve building unprecedented systems (bridge-building for starters, since no two bridge locations are the same - the reuse of bridge design principles is more akin to code reuse, or better yet algorithm reuse). And don't be fooled by what passes for "engineering" education in most software "engineering" classes - it is emphatically not engineering. I suggest you look up some of David Parnas' writings on software engineering if you want to understand what software engineering should be if it is to deserve the name engineering.
The sad thing is that real world experience (in either software dev or in "real" engineering) will teach you that this attitude is completely wrongheaded. Blindly following a process will not automatically lead to good results. The people who claim that are the ones that want to mechanize and commoditize engineering. Real engineering is a creative endeavour. Yes, it helps to have some guidelines and a framework for what kind of documentation you need to produce. But more important is to understand why you are producing that documentation, and how it helps you to reach your goal (which is to produce a good product). Too many people document "because we're supposed to", and, because the don't understand why they're doing it, they do a crappy job. The document is ultimately useless, but the appropriate process box has been checked, so everything's ok.
Real quality stems from having a commitment to producing a quality product, and creatively applying the tools available (analyses, documentation, test, etc) to ensure that your commitment is fulfilled. It doesn't come from blindly following step-by-step procedure: too often the result of that is a failed project, and a bunch of people standing around saying "it's not my fault - we followed the procedure!"
Bottom line: the SEI talks a good line, but they are severely detached from the real world (at least based on my own real-world experiences in several different fields of engineering).
Civil engineering isn't done that way either. I suggest that before you try to claim that software isn't engineering you first gain an understanding of what engineering is.
I think most of the people arguing about whether software development is "craft" or "engineering" have no idea what real engineering actually involves. Design is a creative process. Even engineering design.
Uh, have you ever actually done any engineering? It's as much a "craft" as software "engineering" is. Design is a fundamentally creative process. The difference between software "engineering" and "real" engineering is that real engineers have mathematical tools that allow them to analyze the designs that they have (creatively) developed, and to determine whether or not said designs will meet their requirements. Without having to go to the expense of a full-blown implementation. Such tools exist for software development too. They're just rarely used.
I don't recall MD saying they'd need super-light tanks to get the Delta Clipper to work. Nor did Gary Hudson claim he needed super-light tanks for Phoenix, Roton, or any of his other designs. And as I mentioned before, Douglas Aircraft seemed to think the idea was feasible (both technically and economically) even with 60's technology.
That's funny. Douglas Aircraft Co thought it was feasible in the 60's. Gary Hudson has been working on SSTO since the 70's, and cites several efforts by other companies. Even NASA bought off on the idea when it started the X-33 program. They just botched it by picking a vaporware design that involved all sorts of innovations above and beyond SSTO. So why exactly are you claiming that SSTO "isn't feasible (yet)"?
Perhaps the USPTO needs to look into the patent filing equivalent of BitTorrent (quick, somebody patent that idea!)
Ajax is not new. There are plenty of folks that were doing "Ajax" before it was called "Ajax". Google being one of them. Ajax is just a buzzword.
The problem arises in attempting to define what should be private and what should be communal. And more importantly, in defining who has effective control over "communal" property.
Individuals have a nasty habit of trying to assert "communal" control over putatively private property, simply because they object to how the current owners are using it. Those who maintain effective control over "communal" property have every reason to go along with this, since it increases the amount of stuff over which they have effective control. That is why we see a constant fight for the maintenance of "private property rights" in "legitimately democratic nations". That is why nations that formerly leaned more on the "private property" side of the private/communal line have slipped more towards the communal side (cf the recent US Supreme Court decision wrt eminent domain).
More to the point, just because a nation has adopted (through democratic means) some particular private/communal split, there's no reason that those who want more private property cannot campaign for it - what's the point of a democracy if the only "right" choices and opinions are those that lead to more communal control?
The notion of private property has proven to be a useful social construct for eliminating "tragedy of the commons"-style misuse of resources, and for providing a framework that minimizes fighting over control of resources (if we both agree that "what's mine is mine and what's yours is yours", we won't fight over what to do with those resources - we can save out fights for other issues :-). Is private property required for liberty? Depends on how you define "liberty", doesn't it. The question is, what kind of "liberty" leads to a sustainable society that we'd all like to live in?
I never claimed that it did.
Having said that, I have three questions for you:
Evolution and speciation has been observed (both in the fossil record and in the present day). These are the phenomena.
2. Formulation of an hypothesis to explain the phenomena. In physics, the hypothesis often takes the form of a causal mechanism or a mathematical relation.
Natural selection is the hypothesis to explain the observed phenomena.
3. Use of the hypothesis to predict the existence of other phenomena, or to predict quantitatively the results of new observations.
The natural selection hypothesis has been used to predict what kinds of new discoveries we should expect to find in the fossil record, and to predict how controlled breeding programs are likely to turn out.
4. Performance of experimental tests of the predictions by several independent experimenters and properly performed experiments.
Many paleontologists over the years have discovered new "intermediate" forms, as predicted by natural selection. Animal and plant breeders have been independently experimentally verifying the mechanism of selection ("artificial" in this case, but the principle is the same - any controlled experiment is necessarily "artificial") in the evolution of species for a very long time now.
As I said before: evolution, the phenomenon, is an observed fact. A theory of evolution is an attempt to explain the observed fact.
Err, that side of the moon isn't dark, so calling it the "dark side of the moon" is somewhat misleading. Perhaps you should have used the term "far side of the moon" instead.
*Note the parallels with gravitation: gravitational attraction between objects is a fact. Theories of gravitation seek to explain how that attraction works, thus allowing us to make predictions about how systems under the influence of gravity will evolve over time.
Oh, I'm sure that it would only ever get used to reduce or eliminate harmful activities. The problem lies in the definition of what constitutes "harmful activities". And who gets to make that definition.
TFA isn't really about CS. Mostly they seem to be talking about IT work, and perhaps some programming. Neither of which are really the guts of CS, even if they do get conflated with it on a regular basis. The article makes a big deal out of the fact that DeVry and Strayer are churning out lots of "CS" graduates compared to traditional CS programs. But both of those institutions provide vocational training, and quite clearly cater to a different market than the 4-year colleges. I don't know about Strayer, but DeVry (according to their website) doesn't even offer a "Computer Science" degree, just degrees in "Computer Engineering Technology" and "Computer Information Systems".
"Cyber" is derived from the Greek word for "pilot", or "controller". Norbert Wiener introduced the term into English when he started talking about "Cybernetics" - which was his term for complex feedback control systems (Cyber. Control systems. Kinda makes sense, huh?). How we morphed from Wiener's original usage to the current fad for prefixing "Cyber" onto some random word in order to make it seem computer-related (not even control-related!) is beyond me. Although I'm sure William Gibson deserves a pretty large portion of the blame.
I'm curious: why apply access controls on a per-folder rather than a per-file basis? Seems like the latter would be more flexible, since I may have several different types of files (with different access requirements) in a given directory (of course, since directories == files in Un*x the same would approach would apply to directories). Or is that the way SELinux works already (I have no experience with it)?