Blasphemer! How dare you make pronouncements about my religion? Just because you think it's not a religion - and you try to bring these so-called logical arguments to bear in support of your position - well, that runs utterly counter to my belief system, and so I find it utterly offensive.
If we're going to entertain a privilege for belief systems to be protected from extreme forms of criticism, then the same protection must extend to mine. Otherwise, mine is being discriminated against.
Surely that's the point of this legislation? Mine is a belief system because I say so. I believe fervently in it; that's what matters, not what you believe, not the language you use to defend your nonbelief, nor the number of people who share it.
The foregoing may be taken as self-mocking, but it also happens to be true. Fucking stupid hair analogies anyway.
"How much hair have you got?"
"I've got zero hair."
"That's stupid. Zero isn't an amount of hair."
"Well, I say it is."
"Well, I say it isn't."
"Well, fuck you man."
"Well double fuck you."
"Help! My belief system is under attack."
"No, mine is."
"Hey, I said it first."
"No you didn't. You just weren't listening when I said it.
"What? No fair!"
"Sure it is. As long as we're operating in the realm of subjective belief, anything that either of us might claim, no matter how arbitrary, has to be held as defensible."
There is no substitute for having a general-purpose programmable device, in other words a computer, because it realizes the ideal of limitless adaptive capability. Everything else - form factor, weight, battery life, link speed, keyboard size, screen size, audio quality, you name it - can be viewed as a constraint on that capabilility.
Okay, that's a bit of hyperbole there. But still, it's useful to think in terms of reducing constraints and not just adding features. That's why the idea of having multiple devices to deliver multiple features fundamentally makes no sense. It's not just the clutter and burden of it all, it's the lack of integration which places a constraint on capability.
Take measuring instruments, for example. Which would be more useful, an air pollution sensor with its own little keyboard and screen, or a sensor which interfaces to your personal compute node which also - by the way - has access to a GPS receiver?
It's in the integration of this data where patterns can be detected. The data is already lying out there in the universe, we might say, only needing to be sensed. Some of our artifacts get in the way of sensing that data more than others. Why constrain it to a linear stream of samples on an isolated device when it could be had as a spatial map all ready for further processing? And any ad hoc integration, no matter how prosaic, requires a similar kind of general capability.
If you, as a manager, suddenly lose a skilled but uncommunicative developer, finding the programs he used to hack on the code will be least of your problems.
Exactly. It's just one of several surfaces we have to be concerned about. Thanks for helping to make this point.
Any developer who can't competently administer his own machine is incompetent.
I agree. However, in my 32 years in the industry, I've only met three developers who would qualify as competent under that definition, and that includes people who write network stacks, device drivers, and other system software. For that matter, I've only met a handful of system administrators who are truly competent. The vast majority, in both camps, have respectable skills, but very few of them have the humility to understand that they're functioning in a state of incomplete knowledge and imperfect execution. For a developer, a momentary breakage just means try again. For a system administrator, a momentary breakage means we don't know what information has been exposed.
The kind of rigorous thinking required is identical.
No, it's not. There is a lot of overlap, of course, but two different kinds of rigorous thinking are required for these two functions. A developer foremost has to think about functionality. A system administrator is also responsible for ensuring non-functionality, so that there are zero occurrences of gaps in which the the cat might possibly get out of the bag. I observe very few developers who get that shortcuts, even really really clever shortcuts, are not okay. This whole thread is evidence of that. Conversely, most system administrators are not required to be programmers at all, let alone excellent ones, so they don't see the extent of the design discipline which developers have to work within. They, too, cut corners, but of a kind related to structure. In a perfect world, yes, there is a synthesis of these two disciplines. Alas, very few workplaces promote that synthesis.
I'd be highly reluctant to work at a place that didn't let me install and manage the software packages I needed to do my job.
I hope you'll forgive me for using this last comment to illustrate why you're exactly the kind of person who should be given minimal privileges. I'm sure that your intentions are the best, but you fundamentally don't get it. The computing environment that you're working in is not your personal toy. I'm sure that sounds condescending, but it's the brutal truth. It's not yours, not in any sense. It has to be built and managed in such a way that you could leave and it would carry on fine without you. Think about what that implies. If you need development tools that nobody else needs, then how are the rest of us going to maintain your work product when you're gone? If they're really so important, or so harmless, then everyone should have access to them. Everyone should be running the same versions of them. And any support and security implications in them should be adressed across the board, so that the software which you write can be maintained. It makes no sense at all for individual developers to make these choices or implement them. For that matter, your job isn't defined by you either, is it? Management sets your goals and provides the resources to achieve them. I hope that there's a dialogue around this, so that you can help to define what tools you need. But no, this display of entitlement, thinking that you can just go off and do your own thing, is why you won't get elevated privilege.
Yes, there has to be a place for developers to freely advance new ideas and test them, to try new tools and debate their merits and so on. What we're talking about is a research lab, not the development environment and not your desktop. Good developers deserve access to a good research lab. If I were you, I'd campaign for that, where you stand a chance of winning.
The first thing I do when I'm getting to know an unfamiliar program is pick a couple of the methods or functions more or less at random, and read them carefully.
After 37 years of programming, I've learned that it's critically important to understand the abilities of the person who wrote the code, in order to be able to later determine, when looking at something strange and mysterious, whether it should be treated as cleverly thought through or as just the ordinary inattentive crap that seems to be the standard for most professionals.
Right now I'm doing a code review where All The Comments Are Capitalized And Deliver Important Information Such As We Are Now Initializing Some Variables. The program contains numerous blocks of (nearly) identical code. It contains long variable names which are clearly intended to be self-documenting: names such as iterationCounter or numberOfRowsReturned. This is code that's crying out to be cleaned up and refactored. It's funny how many chronic bugs go away when I do that.
Google executives will have to take their place in line.
I plan to launch a similar action against these Italian politicians. After all, it was their country in which the crime took place. They stood by and permitted it to happen, didn't they?
To make matters worse, they haven't even responded to my letter demanding an apology. That's right. I sent it to Gino's Italian Deli in Montreal. It says "Italian Politicians" right on the envelope, so I know that it was addressed properly. If there was any doubt, it could have been forwarded to the Italian postal service.
I developed a similar system. This particular product is not restricted to voice, but supports any network device which can mirror its packet traffic.
Under its present interpretation, CALEA applies to any sort of subscriber data. If law enforcement can clearly identify the subscriber and the intercept period, the network provider is obliged to supply all data carried for that subscriber during that period. That could be your voice traffic or web browsing or email or whatever. The plant has to be engineered accordingly, but that's essentially a capacity issue.
On the other hand, it's important to note that there is no obligation upon the provider to interpret the supplied data. Such an obligation would be unreasonable and unenforceable. Instead, law enforcement is basically getting a raw PCAP file.
I'll tell you what I found to be the most interesting aspect of this project. There is very strict language in CALEA against intercepting data except for the specified subscriber during the specified period. Of course we were careful to implement controls over that. But until I insisted on the point, nobody even considered that we might want to have controls to verify that the intercept request came from a bona fide court and that the intercept data would be sent to a bona fide law enforcement agency.
Nobody in their right mind actively goes out to seek the hardships that deliver these fundamental insights. It would be much easier to just float along in life, working toward our endless list of what we consider to be self-evident goals.
Nobody wants an existential crisis to get in the way of all that. But if it does, something extraordinary can happen. You're forced to reevaluate everything you stand for. If you have the moral courage to see that as a necessary exercise and give it your best effort, some amazing things can happen. Humility is the most essential discovery of them all. It's something like being reborn. Your ego has to let go of its need to preserve the status quo.
You just can't go out and buy that sort of wisdom. Almost by definition, you have to be dragged kicking and screaming toward it. But such freedom afterward!
Men who don't take strange women's clothes off are men.
Men who do take strange women's clothes off are men too. I don't think that's the issue.
About twenty years ago, I stopped going with colleagues to watch exotic dancers. I paid a small professional cost, perhaps, in being the odd man out, but it seemed a fair trade for peace of mind.
I realized that I could not be comfortable with the rules of the game. Atom Egoyan illustrates this point well in the film Exotica. To create a setting of sexual arousal without corresponding social freedom and compassion is essentially perverse.
Just because a natural impulse can be monetized doesn't mean that it should be, especially if it involves forcing the participants, both dancers and patrons, into hyperconstrained roles that dehumanize their relationship to each other.
The trouble with supercomputing is that, if you have to share the thing, you don't need it.
You are misinformed.
Most computer use, whether at a single workstation or a supercomputer cluster, is extremely bursty. A given user wants rapid turnaround for any particular computation, but otherwise leaves the system completely idle.
This condition explains the success of consortia like TeraGrid and WestGrid which make vast computational resources available to a large user population. Those users could not possibly afford the cost to house, develop, and maintain equivalent facilities on their own, especially when they know that such facilities would be idle most of the time.
It's also incorrect to claim that supercomputer clusters are based on custom hardware. The classical Beowulf cluster is based on commodity hardware. These clusters are commonplace. Of course this situation doesn't prevent the development of more exotic systems for more specialized purposes, for example shared memory or vector processing architectures. But again, these are much easier to justify when their resources can be shared across a community of users.
Web farms generate a completely different usage pattern. Most websites sustain a fairly steady load, or at least one which exhibits predictable, often diurnal, usage patterns that tend to balance out around the clock when serving a global client population. Such patterns are several orders of magnitude less bursty than typical cluster computing jobs. The resource management discipline is consequently very different between the two.
I've known some good recruiters and a lot of mediocre ones, but I'll tell you one thing they all have in common. They all tell me how important it is for us to coordinate on making the approach to a prospective client/employer.
It's entirely possible that I will find the prospect on my own, and it's always in my interest to do so. The recruiter meanwhile gets some mileage simply from being able to say to a client, "Look, here's a synopsis of all the great candidates we have for you. Let me know if you're interested in any of them." A long and illustrious list is impressive. Having my credentials on there adds to its value, even if nothing else ever develops.
In return, I have an arrangement with the recruiter in which he or she checks in with me to get permission to send the client my resume and talk about setting up a meeting. That's our chance to be sure we're not both making the approach at the same time, because the optics if we were to do that would not be good.
Recruiters will claim that what they offer is relationship. The better ones live up to this claim, and those are the ones who understand the need for the sort of arrangement I've described. It's not me coordinating with them, it's them coordinating with me. It's not reasonable for me to call them up every time I sent off a resume to some firm. At that rate, there would be half a dozen calls a day sometimes.
I'll call them when I become unavailable. That seems like a reasonable courtesy to me, and moreover it makes me look good, so there's a logic under which that becomes the behavior expected from professionals. Conversely, it certainly would not be reasonable for them to approach a client without my knowledge and without having checked in with me. That's just dumb on their part. That's no relationship. Sending me in cold, without getting our story absolutely straight beforehand, is a good way to make them and me look bad.
First of all, let's agree that all news reporting is necessarily selective, therefore necessarily expresses the value system of the reporter. Also, any individual who constitutes an audience to the news brings his own set of values. We could perhaps call that a "bias", except that bias implies a position which is not merely nuanced in various ways but aligns those various nuances consistently in some direction.
There are certainly news organizations and individuals who are biased in this sense, but it does not follow that bias is inevitable. That would be equivalent to claiming that any complex multivariate system can be reduced to a single variable.
People DON'T associate glory with things like having 2 routers able to ping each other
Well, I do. Sometimes, anyway. People in science and engineering understand that not all of the really pivotal discoveries are accompanied by a parting of the heavens and a beam of golden light.
And, in my thirty years working in the industry, I've observed that most organizations either have no security policy or have a rather tenuous linkage between the policy and its implementation.
Here's one example. On the first day at one of the smarter places I worked, I came back from a washroom break to find my screen locked with a cutesy warning from the manager of another group (in other words, not in my chain of command). I asked him why he felt that it was his business to tamper with my operations. He condescendingly explained his views on the matter. Fine, I said, are these your personal views or is there some kind of policy or guideline that you'd like me to know about? It turns out there was neither, and no training nor orientation for new staff, a lot of system capabilities that were left wide open, and very diverse practices among the seasoned staff.
The problem I have with situations like that is that they are profoundly irresponsible. It's one thing to have a computing environment that is basically adrift in terms of security. That's fine, if the organization determines that it's not a concern, and takes responsibility for the consequences. But to download that responsibility onto people who have literally just walked in the door is not only unethical, it's doomed to fail.
How many times have people fixed a linux distro to make it easier to do a task. Cat, Grep, etc. Rather than programming in perl all the time to get basic features, these tools have been added to make it easier.
Um, no. Commands like cat and grep have been around since the beginning of Unix. Perl is only about 20 years old.
We live in an era where software vendors specifically disclaim merchantability or fitness of their products.
In other words, the owners of the targeted system knew or ought to have known that the system was vulnerable long before it was hacked.
This is an atrocious state of affairs, of course. It amounts to a kind of complicity of negligence between software vendor and software purchaser. That's not to excuse deliberate hacking activities. But if the victim didn't perform due diligence before the incident, I don't quite see how the hacker can be required to remedy the situation after the incident.
You make a really good point here concerning cable management.
While of course it's possible to produce a very neat cable layout when all cables are built to the exact length required, it's a lot faster, and generally cheaper, to use manufactured cables. But then you're left with the problem of what to do with various small coils of cable. It's not a big problem, but one which deserves some thought in advance of planning your cable runs.
I used to build a lot of rolling equipment racks for robotic control systems. Cable management was an awkward issue there, because you need cables to be neatly dressed within the rack for reasons of sanity, and you need to be able both to keep the cables bundled together when trained across the floor or laid through cable trays, and also to have them separated at the points where they must be led to their respective devices. Finally, there was surplus cable length to be stowed inside the racks. I didn't use hooks, as you suggest, but when allocating space for rack equipment, I did make a point to reserve vertical surfaces to tie off the coiled cable. It's essentially the same issue at home.
There is a branch of statistics called Decision Theory which uses expected values which have a subjective weight. Thus the value of a dollar, say, may not be the same at two points in the equation.
Indeed! Unless you run your own CA, there is not much assurance that identities are being properly verified when certificate requests are signed. I think we've all come across practices to make us livid.
Oh, but wait! Now there's "extended validation"! In exchange for extra money, the CA will promise to exercise the level of care that you thought you were getting from the old identity verification process.
You're on the right track, for sure. As we're talking about fundamentals and not implementation details, the key phrase again is "in effective possession". I can't add more to what I've already offered on that subject.
I often speak in favor of operating a certificate hierarchy, as you've described. But notice that spreading the risk across multiple points of failure not only increases the intrinsic risk of failure, it multiplies the cost of managing the certificate infrastructure. A secondary risk is introduced by that increased cost, because the incentive becomes greater to cut corners somewhere, not to mention that procedural oversight is far from trivial to assure. But I like the containment that, in principle at least, becomes possible within different secondary authorities.
Agreed. A diagnostic model that depends on secrecy already known to be compromised is not a reliable model. It was always brittle, and not uncontroversial. Now it's broken.
Slashdot Mirror
Blasphemer! How dare you make pronouncements about my religion? Just because you think it's not a religion - and you try to bring these so-called logical arguments to bear in support of your position - well, that runs utterly counter to my belief system, and so I find it utterly offensive.
If we're going to entertain a privilege for belief systems to be protected from extreme forms of criticism, then the same protection must extend to mine. Otherwise, mine is being discriminated against.
Surely that's the point of this legislation? Mine is a belief system because I say so. I believe fervently in it; that's what matters, not what you believe, not the language you use to defend your nonbelief, nor the number of people who share it.
The foregoing may be taken as self-mocking, but it also happens to be true. Fucking stupid hair analogies anyway.
"How much hair have you got?"
"I've got zero hair."
"That's stupid. Zero isn't an amount of hair."
"Well, I say it is."
"Well, I say it isn't."
"Well, fuck you man."
"Well double fuck you."
"Help! My belief system is under attack."
"No, mine is."
"Hey, I said it first."
"No you didn't. You just weren't listening when I said it.
"What? No fair!"
"Sure it is. As long as we're operating in the realm of subjective belief, anything that either of us might claim, no matter how arbitrary, has to be held as defensible."
Totally with you on this.
There is no substitute for having a general-purpose programmable device, in other words a computer, because it realizes the ideal of limitless adaptive capability. Everything else - form factor, weight, battery life, link speed, keyboard size, screen size, audio quality, you name it - can be viewed as a constraint on that capabilility.
Okay, that's a bit of hyperbole there. But still, it's useful to think in terms of reducing constraints and not just adding features. That's why the idea of having multiple devices to deliver multiple features fundamentally makes no sense. It's not just the clutter and burden of it all, it's the lack of integration which places a constraint on capability.
Take measuring instruments, for example. Which would be more useful, an air pollution sensor with its own little keyboard and screen, or a sensor which interfaces to your personal compute node which also - by the way - has access to a GPS receiver?
It's in the integration of this data where patterns can be detected. The data is already lying out there in the universe, we might say, only needing to be sensed. Some of our artifacts get in the way of sensing that data more than others. Why constrain it to a linear stream of samples on an isolated device when it could be had as a spatial map all ready for further processing? And any ad hoc integration, no matter how prosaic, requires a similar kind of general capability.
If you, as a manager, suddenly lose a skilled but uncommunicative developer, finding the programs he used to hack on the code will be least of your problems.
Exactly. It's just one of several surfaces we have to be concerned about. Thanks for helping to make this point.
Any developer who can't competently administer his own machine is incompetent.
I agree. However, in my 32 years in the industry, I've only met three developers who would qualify as competent under that definition, and that includes people who write network stacks, device drivers, and other system software. For that matter, I've only met a handful of system administrators who are truly competent. The vast majority, in both camps, have respectable skills, but very few of them have the humility to understand that they're functioning in a state of incomplete knowledge and imperfect execution. For a developer, a momentary breakage just means try again. For a system administrator, a momentary breakage means we don't know what information has been exposed.
The kind of rigorous thinking required is identical.
No, it's not. There is a lot of overlap, of course, but two different kinds of rigorous thinking are required for these two functions. A developer foremost has to think about functionality. A system administrator is also responsible for ensuring non-functionality, so that there are zero occurrences of gaps in which the the cat might possibly get out of the bag. I observe very few developers who get that shortcuts, even really really clever shortcuts, are not okay. This whole thread is evidence of that. Conversely, most system administrators are not required to be programmers at all, let alone excellent ones, so they don't see the extent of the design discipline which developers have to work within. They, too, cut corners, but of a kind related to structure. In a perfect world, yes, there is a synthesis of these two disciplines. Alas, very few workplaces promote that synthesis.
I'd be highly reluctant to work at a place that didn't let me install and manage the software packages I needed to do my job.
I hope you'll forgive me for using this last comment to illustrate why you're exactly the kind of person who should be given minimal privileges. I'm sure that your intentions are the best, but you fundamentally don't get it. The computing environment that you're working in is not your personal toy. I'm sure that sounds condescending, but it's the brutal truth. It's not yours, not in any sense. It has to be built and managed in such a way that you could leave and it would carry on fine without you. Think about what that implies. If you need development tools that nobody else needs, then how are the rest of us going to maintain your work product when you're gone? If they're really so important, or so harmless, then everyone should have access to them. Everyone should be running the same versions of them. And any support and security implications in them should be adressed across the board, so that the software which you write can be maintained. It makes no sense at all for individual developers to make these choices or implement them. For that matter, your job isn't defined by you either, is it? Management sets your goals and provides the resources to achieve them. I hope that there's a dialogue around this, so that you can help to define what tools you need. But no, this display of entitlement, thinking that you can just go off and do your own thing, is why you won't get elevated privilege.
Yes, there has to be a place for developers to freely advance new ideas and test them, to try new tools and debate their merits and so on. What we're talking about is a research lab, not the development environment and not your desktop. Good developers deserve access to a good research lab. If I were you, I'd campaign for that, where you stand a chance of winning.
The experience evidently didn't teach that the correct phrase is "rite of passage".
Or maybe spelling errors are a side effect of chronic head bashing.
The first thing I do when I'm getting to know an unfamiliar program is pick a couple of the methods or functions more or less at random, and read them carefully.
After 37 years of programming, I've learned that it's critically important to understand the abilities of the person who wrote the code, in order to be able to later determine, when looking at something strange and mysterious, whether it should be treated as cleverly thought through or as just the ordinary inattentive crap that seems to be the standard for most professionals.
Right now I'm doing a code review where All The Comments Are Capitalized And Deliver Important Information Such As We Are Now Initializing Some Variables. The program contains numerous blocks of (nearly) identical code. It contains long variable names which are clearly intended to be self-documenting: names such as iterationCounter or numberOfRowsReturned. This is code that's crying out to be cleaned up and refactored. It's funny how many chronic bugs go away when I do that.
Google executives will have to take their place in line.
I plan to launch a similar action against these Italian politicians. After all, it was their country in which the crime took place. They stood by and permitted it to happen, didn't they?
To make matters worse, they haven't even responded to my letter demanding an apology. That's right. I sent it to Gino's Italian Deli in Montreal. It says "Italian Politicians" right on the envelope, so I know that it was addressed properly. If there was any doubt, it could have been forwarded to the Italian postal service.
There is no excuse. These people are criminals.
I developed a similar system. This particular product is not restricted to voice, but supports any network device which can mirror its packet traffic.
Under its present interpretation, CALEA applies to any sort of subscriber data. If law enforcement can clearly identify the subscriber and the intercept period, the network provider is obliged to supply all data carried for that subscriber during that period. That could be your voice traffic or web browsing or email or whatever. The plant has to be engineered accordingly, but that's essentially a capacity issue.
On the other hand, it's important to note that there is no obligation upon the provider to interpret the supplied data. Such an obligation would be unreasonable and unenforceable. Instead, law enforcement is basically getting a raw PCAP file.
I'll tell you what I found to be the most interesting aspect of this project. There is very strict language in CALEA against intercepting data except for the specified subscriber during the specified period. Of course we were careful to implement controls over that. But until I insisted on the point, nobody even considered that we might want to have controls to verify that the intercept request came from a bona fide court and that the intercept data would be sent to a bona fide law enforcement agency.
Well said.
Nobody in their right mind actively goes out to seek the hardships that deliver these fundamental insights. It would be much easier to just float along in life, working toward our endless list of what we consider to be self-evident goals.
Nobody wants an existential crisis to get in the way of all that. But if it does, something extraordinary can happen. You're forced to reevaluate everything you stand for. If you have the moral courage to see that as a necessary exercise and give it your best effort, some amazing things can happen. Humility is the most essential discovery of them all. It's something like being reborn. Your ego has to let go of its need to preserve the status quo.
You just can't go out and buy that sort of wisdom. Almost by definition, you have to be dragged kicking and screaming toward it. But such freedom afterward!
Men who don't take strange women's clothes off are men.
Men who do take strange women's clothes off are men too. I don't think that's the issue.
About twenty years ago, I stopped going with colleagues to watch exotic dancers. I paid a small professional cost, perhaps, in being the odd man out, but it seemed a fair trade for peace of mind.
I realized that I could not be comfortable with the rules of the game. Atom Egoyan illustrates this point well in the film Exotica. To create a setting of sexual arousal without corresponding social freedom and compassion is essentially perverse.
Just because a natural impulse can be monetized doesn't mean that it should be, especially if it involves forcing the participants, both dancers and patrons, into hyperconstrained roles that dehumanize their relationship to each other.
The trouble with supercomputing is that, if you have to share the thing, you don't need it.
You are misinformed.
Most computer use, whether at a single workstation or a supercomputer cluster, is extremely bursty. A given user wants rapid turnaround for any particular computation, but otherwise leaves the system completely idle.
This condition explains the success of consortia like TeraGrid and WestGrid which make vast computational resources available to a large user population. Those users could not possibly afford the cost to house, develop, and maintain equivalent facilities on their own, especially when they know that such facilities would be idle most of the time.
It's also incorrect to claim that supercomputer clusters are based on custom hardware. The classical Beowulf cluster is based on commodity hardware. These clusters are commonplace. Of course this situation doesn't prevent the development of more exotic systems for more specialized purposes, for example shared memory or vector processing architectures. But again, these are much easier to justify when their resources can be shared across a community of users.
Web farms generate a completely different usage pattern. Most websites sustain a fairly steady load, or at least one which exhibits predictable, often diurnal, usage patterns that tend to balance out around the clock when serving a global client population. Such patterns are several orders of magnitude less bursty than typical cluster computing jobs. The resource management discipline is consequently very different between the two.
I've known some good recruiters and a lot of mediocre ones, but I'll tell you one thing they all have in common. They all tell me how important it is for us to coordinate on making the approach to a prospective client/employer.
It's entirely possible that I will find the prospect on my own, and it's always in my interest to do so. The recruiter meanwhile gets some mileage simply from being able to say to a client, "Look, here's a synopsis of all the great candidates we have for you. Let me know if you're interested in any of them." A long and illustrious list is impressive. Having my credentials on there adds to its value, even if nothing else ever develops.
In return, I have an arrangement with the recruiter in which he or she checks in with me to get permission to send the client my resume and talk about setting up a meeting. That's our chance to be sure we're not both making the approach at the same time, because the optics if we were to do that would not be good.
Recruiters will claim that what they offer is relationship. The better ones live up to this claim, and those are the ones who understand the need for the sort of arrangement I've described. It's not me coordinating with them, it's them coordinating with me. It's not reasonable for me to call them up every time I sent off a resume to some firm. At that rate, there would be half a dozen calls a day sometimes.
I'll call them when I become unavailable. That seems like a reasonable courtesy to me, and moreover it makes me look good, so there's a logic under which that becomes the behavior expected from professionals. Conversely, it certainly would not be reasonable for them to approach a client without my knowledge and without having checked in with me. That's just dumb on their part. That's no relationship. Sending me in cold, without getting our story absolutely straight beforehand, is a good way to make them and me look bad.
First of all, let's agree that all news reporting is necessarily selective, therefore necessarily expresses the value system of the reporter. Also, any individual who constitutes an audience to the news brings his own set of values. We could perhaps call that a "bias", except that bias implies a position which is not merely nuanced in various ways but aligns those various nuances consistently in some direction.
There are certainly news organizations and individuals who are biased in this sense, but it does not follow that bias is inevitable. That would be equivalent to claiming that any complex multivariate system can be reduced to a single variable.
People DON'T associate glory with things like having 2 routers able to ping each other
Well, I do. Sometimes, anyway. People in science and engineering understand that not all of the really pivotal discoveries are accompanied by a parting of the heavens and a beam of golden light.
Absolutely agreed.
And, in my thirty years working in the industry, I've observed that most organizations either have no security policy or have a rather tenuous linkage between the policy and its implementation.
Here's one example. On the first day at one of the smarter places I worked, I came back from a washroom break to find my screen locked with a cutesy warning from the manager of another group (in other words, not in my chain of command). I asked him why he felt that it was his business to tamper with my operations. He condescendingly explained his views on the matter. Fine, I said, are these your personal views or is there some kind of policy or guideline that you'd like me to know about? It turns out there was neither, and no training nor orientation for new staff, a lot of system capabilities that were left wide open, and very diverse practices among the seasoned staff.
The problem I have with situations like that is that they are profoundly irresponsible. It's one thing to have a computing environment that is basically adrift in terms of security. That's fine, if the organization determines that it's not a concern, and takes responsibility for the consequences. But to download that responsibility onto people who have literally just walked in the door is not only unethical, it's doomed to fail.
Agreed, except for the following passage:
How many times have people fixed a linux distro to make it easier to do a task. Cat, Grep, etc. Rather than programming in perl all the time to get basic features, these tools have been added to make it easier.
Um, no. Commands like cat and grep have been around since the beginning of Unix. Perl is only about 20 years old.
We live in an era where software vendors specifically disclaim merchantability or fitness of their products. In other words, the owners of the targeted system knew or ought to have known that the system was vulnerable long before it was hacked.
This is an atrocious state of affairs, of course. It amounts to a kind of complicity of negligence between software vendor and software purchaser. That's not to excuse deliberate hacking activities. But if the victim didn't perform due diligence before the incident, I don't quite see how the hacker can be required to remedy the situation after the incident.
Welcome to technical management! I'm deeply grateful for competent bosses who sacrifice their time to be sure that we don't have to sacrifice ours.
Wow. How hard was that, Microsoft?
You'll get used to it eventually, playing by the rules I mean. Just like the rest of us, you're not above the law.
You make a really good point here concerning cable management.
While of course it's possible to produce a very neat cable layout when all cables are built to the exact length required, it's a lot faster, and generally cheaper, to use manufactured cables. But then you're left with the problem of what to do with various small coils of cable. It's not a big problem, but one which deserves some thought in advance of planning your cable runs.
I used to build a lot of rolling equipment racks for robotic control systems. Cable management was an awkward issue there, because you need cables to be neatly dressed within the rack for reasons of sanity, and you need to be able both to keep the cables bundled together when trained across the floor or laid through cable trays, and also to have them separated at the points where they must be led to their respective devices. Finally, there was surplus cable length to be stowed inside the racks. I didn't use hooks, as you suggest, but when allocating space for rack equipment, I did make a point to reserve vertical surfaces to tie off the coiled cable. It's essentially the same issue at home.
You do realize that the Conservatives form a minority government, don't you?
There is a branch of statistics called Decision Theory which uses expected values which have a subjective weight. Thus the value of a dollar, say, may not be the same at two points in the equation.
Indeed! Unless you run your own CA, there is not much assurance that identities are being properly verified when certificate requests are signed. I think we've all come across practices to make us livid.
Oh, but wait! Now there's "extended validation"! In exchange for extra money, the CA will promise to exercise the level of care that you thought you were getting from the old identity verification process.
You're on the right track, for sure. As we're talking about fundamentals and not implementation details, the key phrase again is "in effective possession". I can't add more to what I've already offered on that subject.
I often speak in favor of operating a certificate hierarchy, as you've described. But notice that spreading the risk across multiple points of failure not only increases the intrinsic risk of failure, it multiplies the cost of managing the certificate infrastructure. A secondary risk is introduced by that increased cost, because the incentive becomes greater to cut corners somewhere, not to mention that procedural oversight is far from trivial to assure. But I like the containment that, in principle at least, becomes possible within different secondary authorities.
Agreed. A diagnostic model that depends on secrecy already known to be compromised is not a reliable model. It was always brittle, and not uncontroversial. Now it's broken.