I suspect there's a bit of a definition issue at play here (with all fault apparently being on my end, given some of the other comments in this discussion). In my mind, DevOps roles are such only if the "Dev" and "Ops" parts are connected--I.e., you manage operations for the software that you've developed. I agree that there are rapidly diminishing or negative returns otherwise. E.g., if you write some Nodejs web services on Monday and troubleshoot MS Exchange/ActiveDirectory integration issues on Tuesday, there isn't much benefit. In that case, however, I'd argue that you don't have a DevOps role, you just have 2 different unrelated roles (which, as I stated, is apparently a definition issue on my part).
The only part that I would argue with is..
The difference is between developers knowing the operations side and being the operations side.
You cannot, in my opinion, "know" the operations side if you have never actually been the operations side. The real question is whether knowing the operations side is worth the effort of being the operations side (at least for a while). In my experience, the answer is unequivocally "yes" (but again, with the caveat that you are the operations side only for the software that you develop, and not for, e.g., rolling out the latest Windows service pack to all users at your location).
I should also clarify that my experience has only been with internal development. The demographic differences with respect to external-facing applications (i.e., user/developer ratios on the order of possibly millions to 1 vs. 10s or 100s to 1), among other things, would necessarily limit the ability of developers to participate in operations.
As you've noted, having to run operations to the exclusion of all development activity would bore you to tears. What that has done is forced me to consider--to a degree and precision that would never have occurred to me previously--how the design and architecture of a proposed solution impacts deployment and operations. Because I did not want to spend all my time supporting the system I mentioned in my previous post, I designed it such that it required about all of 30 minutes every other month to administer, and was easy as hell to troubleshoot in production. This meant a much more complex design, and more difficulty in implementation, but saved me a ton of time on net balance such that I could still spend the vast majority of my time doing more interesting stuff.
If deploying and administering the software that you've developed becomes your full-time occupation to the exclusion of all other activity, then either:
I essentially have this kind of role within my organization. I design, develop, deploy, and support small to mid-tier systems (e.g., the planning system for a $XXXmio/yr global department, with 300+ direct users) while being one of my own customers, as I am actually a business planner (by role) as opposed to developer. I develop systems as a way to do my "day job" much more effectively. Typical tech stack would be Excel UIs, PostgreSQL data store, and whatever else I need in the middle (e.g., nodejs, tomcat, redis, whatever).
What I've found is that, in general, doing the right thing the "right way" is not worth the cost compared to doing the right thing the "wrong way". By definition, in either scenario, the right things is getting done. What most pure developers utterly fail to understand is that in trying to do the former, there is an overwhelming tendency to do the wrong thing the right way instead.
This is because, as Fred Brooks pointed out long ago--and as the "lean startup" movement is re-discovering today--for any non-trivial novel problem you cannot know in advance what the "right thing" is until you've actually tried to implement a solution. Brooks stated this understanding as the need to throw away the first try, and the lean startup movement is essentially defined by a corollary--you have to figure out how to try cheaply enough that you can afford to throw it away and try again (and again, and again if necessary), while progressively elaborating a robust definition of what the "right thing" looks like by using those iterations as experiments to test hypotheses about what the "right thing" is. Doing things the "right way" usually costs so much in time if not capital that you simply can't afford to throw away the first try and start over, or you cannot complete enough iterations to learn enough about the problem.
Now, I'm not saying that you should be totally ignorant of software engineering best practices, design patterns, etc. What I am saying is that there is a limit to how effective you can be in reality if you live purely within the development silo. Having a "DevOps" role (granted, self-imposed in my case) has been one of the best things that's ever happened to me as far as making me a better developer, right up there with the standard oldies like writing your own recursive descent parser and compiler.
In short, it is commonly-accepted wisdom among programmers (for good reason!) that you are more effective if you actually understand the technology stack down to the bare metal or as close to it as you can manage (even if only in abstract-but-helpfully-illustrative examples like Knuth's MMIX VM), and that this understanding can only be gained via practice. It should be obvious that the same is true in the other conceptual direction through deployment and end use.
When it comes time for admission and staying in, a student in the top 10% of a US high school just does not have the ability to compete with his/her counterparts who come from China and India . It is like someone wheelchair bound competing in a 100 yard dash against 10 Usain Bolt clones for a single spot.
What you are seeing is the effect of the top 10% of a country with 300M citizens competing agains the top 0.01% of countries with 1B+ citizens each.
Given that educational opportunity in other countries is also subject to extreme selectivity, those 0.01% have also had the benefit of superior education not just through the system provided, but also due to the peer environment. A genius in a school full of geniuses must learn to work hard to succeed as opposed to being able to coast on the momentum of inherent advantage. The benefit of developing a good work ethic manifests itself in college where even a genius has to apply themselves consistently (if not strenuously) in order to master the material being presented.
Maybe if someone actually spoke the truth while in office the problems plaguing our government would have a better chance of being addressed.
No, but this is probably difficult to understand until you've held or are qualified to hold a position of significant accountability and independent authority. At the level of executive leadership, you have to be cognizant of the consequences--especially with respect to your responsibilities.
Essentially, the problem in this case boils down to the fact that speaking candidly as he is doing now would have destroyed his ability to be an effective Secretary of Defense, as the little cooperation he was getting from Congress and the Whitehouse would have evaporated in an instant. It therefore would have been an irresponsible thing to do while he held that position.
The logic goes something like this:
The responsible thing to do is to pour your energy into fulfilling your responsibilities. If you do not feel that you can fulfill them adequately, resign (after some due dilligence to ensure sufficient continuity in the organization). Wait a while before commenting on your past position and its challenges, as doing so immediately upon resignation is likely to poison the well for your successor. These are the actions of someone focused on doing the best thing to fulfill the responsibilities of the role--up to and including self-removal therefrom if the logical conclusion is that they are not able to effectively do the job.
If you feel that the role of critic is more important than the role you were given, you should not have accepted it in the first place and instead applied to become a journalist/commentator.
The example you gave, if true, is a classic demonstration that IT management does not understand their business, not the other way around.
First, while you may want to approach a person directly to give them a friendly heads-up as a first step, the basic thing IT management is supposed to understand is that a user having weak passwords is not so much a risk to that user but a risk to the business. If a user ignores your friendly heads-up, or the problem is more widespread than 1 person, the next step is to go to the person responsible for that part of the business. Now, you don't have to be a douche and call out the specific individual(s) in question, but you then tell that person that there is a systemic risk to their operation because X% of users (or alternatively, a few users with extensive access rights to critical systems) have weak passwords that all appear near the top of
The key thing that even moderately competent managers (IT or otherwise) understand in these kinds of situations is that you have to put the decision (and relevant information) in squarely in the hands of the person accountable and responsible for the issue. In this case the issue is not that someone has a weak password that might result in someone messing up their My Documents folder, it is that weak passwords are a risk to the business. If a bank comptroller's password is 'password', that is not a problem-waiting-to-happen for the comptroller, it's a ticking timebomb for the bank.
In your example, you do not put the decision to act (or not act) in the hands of the account owner, but in the hands of the account owner's business unit head.
Security and IT issues in general tend to get short shrift in many business (at least in my personal experience) not so much because non-IT/non-technical managers are stupid, but because the IT managers lack even basic competence relative to the second half of their title.
Your parent's statement is not an oxymoron.
If every single print driver has components running in both ring 0 and userspace, but the preponderance of components (by number or 'size') of every single print driver is in userspace, then it is more precise to say that "all print drivers are mostly in userspace" as opposed to "printer drivers are mostly in userspace". The latter is semantically a superset of the former, as it could either mean the same thing, or also describe a situation where some printer drivers are completely implemented in ring 0, but the majority are completely or mostly implemented in userspace such that the preponderance of the set of all printer driver implementations resides in userspace.
In other words, your parent's statement is more precise about not only the aggregate population of printer drivers, but the distribution within the population. Whether that statement is actually correct or even the real intent of your parent poster's statement is another question
First, disagreements aside, thank you for taking the time to respond. I am genuinely interested in trying to understand more about the topic (for my own personal benefit if nothing else) and that is harder to do in a vacuum if there is no discussion. Also, I do apologize if I mix up terms in a way that hampers discussion.
Mind-brain devolves to brain = magic if we must accept that the brain is special in some way that makes it immune to analysis. If it is not, then it is functionally identical to and scientifically indistinguishable from a biological implementation of the Chinese Room with a critical modification (the removal of the arbitrary requirement that all input to the CR be reduced to symbols). The Other Minds response highlights this problem well, and Searle's response that the the assumption that other people are conscious is necessarily axiomatic is either a strong indication that his definition of consciousness irrelevant to science (faith in the consciousness of others (or even the self) is a not a falsifiable position) or begging the question. Note that I did not say that his meaning is unimportant (it could still be the most important question ultimately facing any intelligent existence), but it is simply outside of the scope of science. The third option is to fall back on the broader symbol grounding issue as you seem to be doing.
The core of the argument is that you can't get semantic content from purely syntactic content. Ultimately, it's an attack on computationalism, and a damn good one.
That statement just raises the Connectionist argument that the validity of the CR thought experiment depends upon the false premise that all computation is necessarily syntactic. Searle specifies as axiomatic to the CR argument that any program must be symbolic, and further implies that any programmable computer must therefore only be capable of symbolic manipulation, and as such the CR argument a priori limits the scope of the problem to the syntactic. As such, the CR does not simulate the overall physical reality of, e.g., the propagation of pressure waves and the subsequent audio-neural transduction (hearing Cantonese) or the EM-neural transduction (seeing Chinese characters on a page). This then limits the interaction of the system with the outer world as occurring through a filter stripping that interaction of all a-symbolic and sub-symbolic components. We can contrast this with the experience of a native Cantonese speaker, for whom hearing spoken Cantonese or seeing pinyin characters on a page is a fundamentally non-symbolic interaction that only becomes symbolic after being processed by the brain. The original CR is therefore fundamentally flawed in its conception or inconsistent in its premise that the CR can perform in a manner identical to a real intelligence while stipulating conditions that are impossible to impose on, e.g., a human intelligence. Even the CR-inside-a-mind modification later articulated by Searle exhibits this flaw as Searle’s consciousness still filters and strips all non-syntactic input before passing it to the internalized CR.
To paraphrase parts of the Connectionist argument, the view that all computation as identical to manipulation of meaningless syntactic constructs is an observer-dependent interpretation that unjustifiably excludes the physical reality of the computer system, which has structure and properties independent of our choice to view the cascade of physical interactions as manipulation of symbols. In short, a la his wordstar-on-the-wall argument, Searle is correct in asserting that a program in the abstract is a collection of symbols that has no inherent meaning, but it is incorrect in asserting that a physical system responding to inputs that we perceive to be a program is identical to that abstract concept, and that because the one of many real inputs into the system to which we assign meaning is symbolic to us, that the system’s response is necessarily and only symbolic.
In any case, Neural net modeling, which was the original topic of this discussion, is essentially focused on studying non-syntactic computation. If the response to this is that it is still flawed because ANNs are mostly implemented on digital (and therefore nominally symbolic) computational systems, then, even ignoring the point of the larger system above, this objection reduces to a simple implementation technology issue as opposed to a fundamental constraint of ANNs as an ANN is not necessarily limited to implementation on nominally digital platforms. If implementation on digital logic is found to be fundamentally limiting for some as-yet unknown reason, then that can be addressed via moving to analog, quantum, or biochemical systems (which, taken to the extreme, could simply be an artificially constructed human brain).
In essence, while I agree that the cognitive model of the mind processing symbols to which we assign meaning is flawed, it is incorrect to assert that computation is necessarily limited to this model. In that view, the CR only addresses a very narrow class of AI based on the reality/interaction -> symbol -> meaning cognitive model, where the mind's interaction with reality is mediated by a purely symbolic interface, as opposed to the connectionist model of reality/interaction -> a-symbolic sensory input -> meaning -> symbol where symbols are only created as a result of assignment of meaning, and then later inserted into the cognitive process as useful filters or abstractions that allows the mind to more quickly/efficiently deal with inputs. This model of the cognitive process rejects Searle's CR as valid as in this context the CR argument's premise begs the question by imposing the restriction that symbols must be specified before meaning is assigned (i.e., they are not symbols to the CR, but are in fact someone else's symbols), and the more subtle inference that the system must ultimately respond to each symbol as a hypothetical native Chinese speaking conversation partner (or otherwise immediately pass the Turing test as applied by a Chinese speaker) in order to qualify as being conscious. In order to do so with a foreign set of symbols that have not been internalized by the consciousness means it must either fail the Turing test or to simply get inside (or alternatively internalize) the Chinese Room and process symbols via complex lookup. As passing the Turing test is a premise of the CR, then we are left with the latter scenario whereby even an assumed consciousness, being forced to work with symbols created by someone else to which it has not developed or assigned any meaning, must simply respond to inputs mechanically based on the rules it has been supplied a premise of the though experiment. In other words, even if a consciousness does exist, it cannot simultaneously understand Chinese and satisfy the other premises due to the conditions imposed by the thought experiment, so the possibilities of the CR are a consciousness that does not understand Chinese, or a lack of consciousness and simple mechanical symbol processing. The conclusion of the CR argument is therefore a recursive and inevitable outcome of the combination of the reality -> symbol -> meaning cognitive model and the conditions of the experiment.