I've been practising Buddhism for forty years and have only rarely encountered any discussion concerning the existence or nature of a "soul". It's not something that Buddhists tend to concern themselves about.
In fact, quite the converse. A fundamental observation of Buddhism is that dualism is illusory. Therefore, questions of whether there is or is not a soul are not meaningful from a Buddhist perspective. The doctrine of anatt> what appears in the Pali canon is very clear on this point.
Twenty years ago, while in Germany, I saw a television documentary which described the United States as a "dollar democracy", ie. one dollar = one vote. It's overly simplistic, of course, but has more than a little truth to it.
With relationships like these, you can present different generic views into the same page set. One point I'd add is that it's useful to have, as the primary hierarchical structuring of the data, a fairly accurate reflection of the way the business itself is organized.
After all, computing infrastructure is essentially a model of the business, plus additional technical constraints. There should be a strong isomorphism between the two. If your documentation reveals this, not only can everyone navigate through the wiki without getting lost, you can sometimes also identify gaps in both the docs and the IT environment itself. It's a great way to work with senior management.
You're sort of right, but you've only listed half of the factors which influence efficiency. For example, the rate of combustion is a function of fuel chemistry, not engine speed, so it's less complete at higher speeds. Ignition timing only partially compensates for this effect. Exhaust scavenging is also compromised at high speeds. Because of numerious factors such as these, the power and torque curves of any internal combustion engine design are far from linear, and likewise it's too much to expect that they will ever match linearly with fuel consumption.
Your sports car is, by definition, optimized for aggressive driving. Points to you for keeping the engine in its optimal power band, but small wonder if the engine fails to perform better outside of it.
There are a lot of BS laws passed that are dumb attempts and nannying you. This isn't one of them.
Agreed. It's troubling to see the development of so much cognitive dissonance in American culture. Resist seatbelt and motorcycle helmet laws, but accept body scans and patdowns at the airport. Oppose universal health care but legislate equal time for creationism in schools. Resist gun laws but build gated comunities and treat high schools like jails. Be suspicious of government but cover elections as if they were popularity contests.
I know, I know. Every culture has its weirdnesses, without exception. You only have to live in one or two other countries to appreciate this. But you also find yourself appreciating what other countries do right. Broadly speaking, I think that what other developed nations have over the US is an abiding sense of community. For example, with a few notable exceptions (soccer louts and neo-nazis come to mind) Europeans tend to favor whatever makes sense in terms of the common good. Having been through two world wars, they have a firsthand experience of facism and react instinctively against it.
Meanwhile, it's perhaps understandable that the emerging pattern of facism in the United States goes almost unnoticed. I didn't intend my comments here to become a political rant, but I guess they have. Sorry about that. All I really meant to do was to encourage Americans to get out more and maybe gain some perspective from within another culture. It's not good to live in insularity.
Absolutely true. I've been developing software for forty years now, and I have only once in my entire career seen anyone's code that didn't fall short of my own standards of clarity and structure. (Mind you, that one exception was absolutely a pleasure to work with.)
I've also observed that the quality of software, as well as the overall degree of professionalism, tends to increase with the age of a software developer. That should be no surprise. Both depth and breadth of experience are valuable assets, and you don't get them without putting in the time.
From everything I've seen, our industry is in dire need of people who have the skills and design insight necessary to program well. That's to say that this need always takes the form of a software development position. From system architects and security people to network administrators and operations staff, there is always value in having someone who knows how to think programmatically, even if they don't actually develop software. But often it turns out that substantial amounts of software development are part of the job, especially if the position has broad responsibilities. Consulting positions often require people who can bring a diverse skill set to the site. Programming is definitely one of those skills, along with requirements analysis and architecture and documentation and people skills and network engineering and so on.
My advice therefore is to broaden your search to include senior technical positions of any kind where you have a genuine interest and some amount of relevant background. A sales engineer has to have great analytical and people skills, so the OP would do well to apply for positions which seem likely to need those skills. Present yourself as mature, articulate, and versatile. It works for me. I've had a long, diverse, and rewarding career that way.
It turns out that most (although perhaps not all) employees job requirements "fit" with the contractor IT model.
Having been tried, it turns out not to be so, not as a practical matter and not in law. I've worked in several countries, all of which have extensive legislation whose effect very much depends on whether you are an employee or a contractor. Taxation, holidays, medical and pension benefits, workplace protections, insurance, liability, intellectual property: they all depend heavily on this distinction.
As a practical matter, any contractor engaged by an organization has to have a contact point within the organization who is trusted by that organization to safeguard its interests. The employee and contractor may work side by side on the same project, and may bring very similar skills to bear, so it's worth examining the differences between then in such a case.
Legislation aside, the relationship between contractor and organization is loosely coupled by means of whatever contract is agreed by the two parties, most often initiated by the contractor. Conversely, an employee doesn't present the employer with a contract. It's invariably the other way round, and seldom negotiable, and in general expressed in tightly coupled terms.
Now, people are people no matter what hats they happen to be wearing, so of course there is always the possibility of malfeasance, incompetence, or actions in bad faith by anyone. However, the legal and sociological expectations are very different for the employee who functions as a contact point and for the contractor as the counterpart in the relationship. Organizations which respect this distinction can develop and enforce effective security policies. Those which don't, quite simply, can't.
Short version: develop metrics that are relevant to delivering on business operations. You need to work with management on identifying these in IT terms. Once you all have a common terminology and something to work towards, you on the IT side can come back with a set of activities that do this. Some activities are sustainment of useful practices. Some are initiatives that have to be planned forward. You're drawing them a map of the terrain and how to get through it. Rough cost each pathway and then work with these folks to figure out what order to do them in.
Somebody owes me ten quatloos here. I'm sure of it.
On the contrary, children can be very helpful with situational awarenss. Parents enlist them for that purpose all the time. My other points stand.
It's worth remembering the obvious, that the purpose of passenger vehicles is to transport passengers. That purpose has nothing to do with talking on cell phones. You're claiming that the distinction between these two is arbitrary. No, it's fundamental.
Totally. Anecdotally at least, it seems that a significant number of drunk driving convictions are for repeat offenses. I knew a couple of guys like this back in university days when enforcement was pretty lax compared to today. They were nice enough guys but somehow, magically, they had multiple convictions at a time when lots of other people were drinking and driving without incident.
I shudder to think about how much drunk driving time these repeat offenders must have racked up before they got unlucky. It's not smart for any of us to drive when we're impaired by any factor whatever, but it seems to be the extreme few who do most of the damage.
Indeed. Due to the nature of the way data is gathered, it's very hard to infer causality from accident statistics in the real world. There are too many significant factors at play, and too few controls. We need to set up a laboratory experiment under controlled conditions. Reports of such research are available and make for valuable reading. But this work is intended for a sophisticated audience and doesn't show up in the popular media.
Instead, all too often the public is given propaganda which relies on hyperbole and faulty inference. It frankly insults our intelligence. For example, we may be told that 80% of road fatalities involve the consumption of alcohol, therefore alcohol is a cause of most road fatalities. This is reasoning ex post facto. Care to guess what percentage of road fatalities involve the consumption of water? Should we therefore infer that water is more dangerous than alcohol?
It would be clearly stretching the point to suggest that alcohol intoxication has no effect on driving ability. But we can't responsibly investigate such claims, either way, without better experimental controls than merely looking at the accident scene. Suppose we observe, for example, that 80% of all drivers are intoxicated. That would account equally well for all the accidents and all the non-accidents. To infer any distinctive correlation, we'd also have to perform random checks over the same population and observe that, say, only 10% of drivers are drunk on average. Then we could conclude that drunk drivers are overrepresented in the accident events. But such data is rarely available, because roadside checks tend to be highly selective, therefore not even approximately random.
And even if we do succeed at showing the correlation, we still can't infer causation. It could well be that risky drivers - the kind responsible for most accidents - don't confine their risky behavior to driving decisions but also to alcohol consumption. Unless we come up with a way of accurately measuring driver ability at random roadside checks and at the accident scene (somewhat difficult in cases where the driver has died), we have no way to compensate for this effect on our real-world accident data.
The difference is that your passengers share your situational awareness. They're in a position to know when to be quiet and let you concentrate. They're in a position to scan for road hazards that you might miss. In practice, these factors are found to substantially compensate for distractions such as conversation. Of course there are extreme cases, but in general passengers are not associated with elevated accident stats to nearly the same extent as use of a cell phone.
I'm inclined to dispute this point, using my own life as an example.
For the past forty years I've been earning a typical income, spending most of it, and saving the rest. That's typical behavior for most people, I hope. When I look at what I've spent it on, almost none of it was ever advertized. For the residue of goods and services that was subject to advertizing, I observe that my buying decisions were not made on the basis of that advertizing but on my own initiative based on need, attributes, and availability.
As a sanity check, I just took fifteen minutes to walk around the house looking at stuff. Hundreds of things. I could find no exception to the above claims.
We can certainly get into splitting hairs on what exactly is marketing. If a product is packaged in such a way that it informatively describes its attributes, that is arguably a form of marketing. Certainly I'm influenced by such information. But I don't think that's what's being discussed here. We're talking about messages whose content essentially reduces to "buy this".
I find no difficulty in identifying those messages and ignoring them. I find advertizing unpleasant, but my activities rarely put me in contact with it. Where they do, I have mitigations. For web browsing, I have ad blocking software. For television, I use this thing called a MUTE button. But I watch it so rarely that it hardly matters.
I don't see what the big deal is. Folks, this is not hard or radical, it's an easy habit. My life is rich and meaningful and totally enjoyable, and my conscience is clear that I'm doing things because I choose to do them, not because some voice has told me to do them.
Yes, an IT manager doesn't need to know how to set up an Exchange server, but they do need to know how to write up their business requirements. This is good surely?
It's good, provided that said requirements are meaningful from an implementation perspective. Doing so requires significant expertise of the very sort which Paul Venezia complains is being downplayed.
This particular fly has been in the ointment for a very long time, since the Mythical Man Month era when software development labor was elaborately divided into system analysis, design, programming, coding and so on. It was horrifically inefficient then; what's happened to make it efficient now?
Does it really serve to have no record of most discussions? If there's a place for formal, minuted, meetings, and a place for informal discussion off the record, surely that implies a continuum. Email serves a middle place in that continuum.
It just so happens that American and English first names are ubiquitous in the Philippines, as are Spanish last names. In the case of Spanish, well, that was colonial. First names, though, that's more or less a matter of [gasp] free choice. I have no idea why, except perhaps that over the centuries Filipinos have developed something of an "adapt or die" attitude toward culture.
No, atheism is an ontological position. It's nothing like religion, in that it's not a belief and does not require belief. Hence the analogy with not collecting stamps.
Moreover, useful configurability is stripped out so that the functions which could easily have been retained as configuration options are just plain gone. Occasionally that may be justified. More often, it's inexcusable.
And while we're at it, I'd like to register my vote for application windows being placed where I configure them to go. Once upon a time, this would have been dead easy to set up with X Resources.
Slashdot Mirror
I've been practising Buddhism for forty years and have only rarely encountered any discussion concerning the existence or nature of a "soul". It's not something that Buddhists tend to concern themselves about.
In fact, quite the converse. A fundamental observation of Buddhism is that dualism is illusory. Therefore, questions of whether there is or is not a soul are not meaningful from a Buddhist perspective. The doctrine of anatt> what appears in the Pali canon is very clear on this point.
Twenty years ago, while in Germany, I saw a television documentary which described the United States as a "dollar democracy", ie. one dollar = one vote. It's overly simplistic, of course, but has more than a little truth to it.
With relationships like these, you can present different generic views into the same page set. One point I'd add is that it's useful to have, as the primary hierarchical structuring of the data, a fairly accurate reflection of the way the business itself is organized.
After all, computing infrastructure is essentially a model of the business, plus additional technical constraints. There should be a strong isomorphism between the two. If your documentation reveals this, not only can everyone navigate through the wiki without getting lost, you can sometimes also identify gaps in both the docs and the IT environment itself. It's a great way to work with senior management.
You're sort of right, but you've only listed half of the factors which influence efficiency. For example, the rate of combustion is a function of fuel chemistry, not engine speed, so it's less complete at higher speeds. Ignition timing only partially compensates for this effect. Exhaust scavenging is also compromised at high speeds. Because of numerious factors such as these, the power and torque curves of any internal combustion engine design are far from linear, and likewise it's too much to expect that they will ever match linearly with fuel consumption.
Your sports car is, by definition, optimized for aggressive driving. Points to you for keeping the engine in its optimal power band, but small wonder if the engine fails to perform better outside of it.
There are a lot of BS laws passed that are dumb attempts and nannying you. This isn't one of them.
Agreed. It's troubling to see the development of so much cognitive dissonance in American culture. Resist seatbelt and motorcycle helmet laws, but accept body scans and patdowns at the airport. Oppose universal health care but legislate equal time for creationism in schools. Resist gun laws but build gated comunities and treat high schools like jails. Be suspicious of government but cover elections as if they were popularity contests.
I know, I know. Every culture has its weirdnesses, without exception. You only have to live in one or two other countries to appreciate this. But you also find yourself appreciating what other countries do right. Broadly speaking, I think that what other developed nations have over the US is an abiding sense of community. For example, with a few notable exceptions (soccer louts and neo-nazis come to mind) Europeans tend to favor whatever makes sense in terms of the common good. Having been through two world wars, they have a firsthand experience of facism and react instinctively against it.
Meanwhile, it's perhaps understandable that the emerging pattern of facism in the United States goes almost unnoticed. I didn't intend my comments here to become a political rant, but I guess they have. Sorry about that. All I really meant to do was to encourage Americans to get out more and maybe gain some perspective from within another culture. It's not good to live in insularity.
Absolutely true. I've been developing software for forty years now, and I have only once in my entire career seen anyone's code that didn't fall short of my own standards of clarity and structure. (Mind you, that one exception was absolutely a pleasure to work with.)
I've also observed that the quality of software, as well as the overall degree of professionalism, tends to increase with the age of a software developer. That should be no surprise. Both depth and breadth of experience are valuable assets, and you don't get them without putting in the time.
From everything I've seen, our industry is in dire need of people who have the skills and design insight necessary to program well. That's to say that this need always takes the form of a software development position. From system architects and security people to network administrators and operations staff, there is always value in having someone who knows how to think programmatically, even if they don't actually develop software. But often it turns out that substantial amounts of software development are part of the job, especially if the position has broad responsibilities. Consulting positions often require people who can bring a diverse skill set to the site. Programming is definitely one of those skills, along with requirements analysis and architecture and documentation and people skills and network engineering and so on.
My advice therefore is to broaden your search to include senior technical positions of any kind where you have a genuine interest and some amount of relevant background. A sales engineer has to have great analytical and people skills, so the OP would do well to apply for positions which seem likely to need those skills. Present yourself as mature, articulate, and versatile. It works for me. I've had a long, diverse, and rewarding career that way.
It turns out that most (although perhaps not all) employees job requirements "fit" with the contractor IT model.
Having been tried, it turns out not to be so, not as a practical matter and not in law. I've worked in several countries, all of which have extensive legislation whose effect very much depends on whether you are an employee or a contractor. Taxation, holidays, medical and pension benefits, workplace protections, insurance, liability, intellectual property: they all depend heavily on this distinction.
As a practical matter, any contractor engaged by an organization has to have a contact point within the organization who is trusted by that organization to safeguard its interests. The employee and contractor may work side by side on the same project, and may bring very similar skills to bear, so it's worth examining the differences between then in such a case.
Legislation aside, the relationship between contractor and organization is loosely coupled by means of whatever contract is agreed by the two parties, most often initiated by the contractor. Conversely, an employee doesn't present the employer with a contract. It's invariably the other way round, and seldom negotiable, and in general expressed in tightly coupled terms.
Now, people are people no matter what hats they happen to be wearing, so of course there is always the possibility of malfeasance, incompetence, or actions in bad faith by anyone. However, the legal and sociological expectations are very different for the employee who functions as a contact point and for the contractor as the counterpart in the relationship. Organizations which respect this distinction can develop and enforce effective security policies. Those which don't, quite simply, can't.
The magic is Citrix, which insulates you from your end user's environment.
Except that it doesn't. What part of "keystroke intercept" does Citrix protect against?
It's fine to play around on the bleeding edge, but here's a message about relevance:
When low tech works, use it.
I like it.
Short version: develop metrics that are relevant to delivering on business operations. You need to work with management on identifying these in IT terms. Once you all have a common terminology and something to work towards, you on the IT side can come back with a set of activities that do this. Some activities are sustainment of useful practices. Some are initiatives that have to be planned forward. You're drawing them a map of the terrain and how to get through it. Rough cost each pathway and then work with these folks to figure out what order to do them in.
Somebody owes me ten quatloos here. I'm sure of it.
On the contrary, children can be very helpful with situational awarenss. Parents enlist them for that purpose all the time. My other points stand.
It's worth remembering the obvious, that the purpose of passenger vehicles is to transport passengers. That purpose has nothing to do with talking on cell phones. You're claiming that the distinction between these two is arbitrary. No, it's fundamental.
Totally. Anecdotally at least, it seems that a significant number of drunk driving convictions are for repeat offenses. I knew a couple of guys like this back in university days when enforcement was pretty lax compared to today. They were nice enough guys but somehow, magically, they had multiple convictions at a time when lots of other people were drinking and driving without incident.
I shudder to think about how much drunk driving time these repeat offenders must have racked up before they got unlucky. It's not smart for any of us to drive when we're impaired by any factor whatever, but it seems to be the extreme few who do most of the damage.
Indeed. Due to the nature of the way data is gathered, it's very hard to infer causality from accident statistics in the real world. There are too many significant factors at play, and too few controls. We need to set up a laboratory experiment under controlled conditions. Reports of such research are available and make for valuable reading. But this work is intended for a sophisticated audience and doesn't show up in the popular media.
Instead, all too often the public is given propaganda which relies on hyperbole and faulty inference. It frankly insults our intelligence. For example, we may be told that 80% of road fatalities involve the consumption of alcohol, therefore alcohol is a cause of most road fatalities. This is reasoning ex post facto. Care to guess what percentage of road fatalities involve the consumption of water? Should we therefore infer that water is more dangerous than alcohol?
It would be clearly stretching the point to suggest that alcohol intoxication has no effect on driving ability. But we can't responsibly investigate such claims, either way, without better experimental controls than merely looking at the accident scene. Suppose we observe, for example, that 80% of all drivers are intoxicated. That would account equally well for all the accidents and all the non-accidents. To infer any distinctive correlation, we'd also have to perform random checks over the same population and observe that, say, only 10% of drivers are drunk on average. Then we could conclude that drunk drivers are overrepresented in the accident events. But such data is rarely available, because roadside checks tend to be highly selective, therefore not even approximately random.
And even if we do succeed at showing the correlation, we still can't infer causation. It could well be that risky drivers - the kind responsible for most accidents - don't confine their risky behavior to driving decisions but also to alcohol consumption. Unless we come up with a way of accurately measuring driver ability at random roadside checks and at the accident scene (somewhat difficult in cases where the driver has died), we have no way to compensate for this effect on our real-world accident data.
The difference is that your passengers share your situational awareness. They're in a position to know when to be quiet and let you concentrate. They're in a position to scan for road hazards that you might miss. In practice, these factors are found to substantially compensate for distractions such as conversation. Of course there are extreme cases, but in general passengers are not associated with elevated accident stats to nearly the same extent as use of a cell phone.
At last, a small oasis of reason.
I'm inclined to dispute this point, using my own life as an example.
For the past forty years I've been earning a typical income, spending most of it, and saving the rest. That's typical behavior for most people, I hope. When I look at what I've spent it on, almost none of it was ever advertized. For the residue of goods and services that was subject to advertizing, I observe that my buying decisions were not made on the basis of that advertizing but on my own initiative based on need, attributes, and availability.
As a sanity check, I just took fifteen minutes to walk around the house looking at stuff. Hundreds of things. I could find no exception to the above claims.
We can certainly get into splitting hairs on what exactly is marketing. If a product is packaged in such a way that it informatively describes its attributes, that is arguably a form of marketing. Certainly I'm influenced by such information. But I don't think that's what's being discussed here. We're talking about messages whose content essentially reduces to "buy this".
I find no difficulty in identifying those messages and ignoring them. I find advertizing unpleasant, but my activities rarely put me in contact with it. Where they do, I have mitigations. For web browsing, I have ad blocking software. For television, I use this thing called a MUTE button. But I watch it so rarely that it hardly matters.
I don't see what the big deal is. Folks, this is not hard or radical, it's an easy habit. My life is rich and meaningful and totally enjoyable, and my conscience is clear that I'm doing things because I choose to do them, not because some voice has told me to do them.
Yes, an IT manager doesn't need to know how to set up an Exchange server, but they do need to know how to write up their business requirements. This is good surely?
It's good, provided that said requirements are meaningful from an implementation perspective. Doing so requires significant expertise of the very sort which Paul Venezia complains is being downplayed.
This particular fly has been in the ointment for a very long time, since the Mythical Man Month era when software development labor was elaborately divided into system analysis, design, programming, coding and so on. It was horrifically inefficient then; what's happened to make it efficient now?
So true.
Does it really serve to have no record of most discussions? If there's a place for formal, minuted, meetings, and a place for informal discussion off the record, surely that implies a continuum. Email serves a middle place in that continuum.
It just so happens that American and English first names are ubiquitous in the Philippines, as are Spanish last names. In the case of Spanish, well, that was colonial. First names, though, that's more or less a matter of [gasp] free choice. I have no idea why, except perhaps that over the centuries Filipinos have developed something of an "adapt or die" attitude toward culture.
No, atheism is an ontological position. It's nothing like religion, in that it's not a belief and does not require belief. Hence the analogy with not collecting stamps.
"Atheism is a religion in the same sense as not collecting stamps is a hobby."
Woot! Score:10.
Moreover, useful configurability is stripped out so that the functions which could easily have been retained as configuration options are just plain gone. Occasionally that may be justified. More often, it's inexcusable.
Hear hear!
And while we're at it, I'd like to register my vote for application windows being placed where I configure them to go. Once upon a time, this would have been dead easy to set up with X Resources.
Mod up. This is a nice synopsis.