A useful distinction can be made between Public Cloud and Private Cloud, and it puts the matter on firmer technical ground.
Private Cloud is when the hardware is yours. It lives inside your firewall and is subject to your security practices. Public Cloud, conversely, is not yours.
Having cleared up that detail, we can talk about what makes it a "cloud" and not just a bunch of services running who-really-cares-where. Essentially, it comes about as a consequence of virtualization. There's a qualitative difference between saying, "I need to buy a server with X capacity in order to run my application," and creating an instance of your application in a cloud. Yes, they both ultimately depend on hardware capacity, but there is a separation of concerns between the abstract resources that your app needs and how they are physically provided. You tend not to think about servers any more but about instances of things. It encourages a more modular, more fluid way of solving problems.
For example, I've been talking with one of my colleagues this week about setting up a package repository. That's a server which delivers software packages for clients to install. New packages have to be added to the repository automatically, and they have to be signed. Now, this raises the awkward question of where to maintain the private key used for signing each change to the repository. We found ourselves having to rule out all of the possible algorithmic options. The essential requirement is that the signing has to be encapsulated inside something that can peform computations. What we really need is a specially hardened server that does nothing but sign changes to the repo. But who can afford to buy a whole server just for that one narrow purpose? If the server is virtual, the resource issue goes away.
Of course, other issues remain. Just as there is an inherent security risk in having unrestricted access to a physical server, there is risk in having comparable access to a virtual server. In principle, disaster recovery in a virtualized environment ought to be more robust than in a physical one, because you can maintain a perfect digital record of everything that went into creating that environment. But even if you keep that record offsite in multiple bank vaults, if you have never tried to actually bring up and test a virtual environment with it, you may be in for a big surprise.
So I don't want to do what the marketing people do and say that cloud solutions are magically wonderful. There's a useful separation of concerns in a cloud solution that, I believe, leads to a more elegant way of approaching design problems. And there's a big difference between private and public cloud that the people selling public cloud services don't really like to talk about. As to whether a cloud solution has specific advantages for you, I think one of the most surprising results is that it comes with a change of thinking.
The big cities it's almost at the point of being ineffective there's so much of it.
Uh huh. Yeah, almost.
This is an absurd discussion. I feel like I'm talking with a creationist. Can't you make even one valid point? Please?
Pardon me, but I took my degree at a school that had a good reputation. In those days, universities did not advertize. If they had, people would have found that to be in bad taste. In most countries, it's still very uncommon.
I travel because I have a reason to go to a place. Do you seriously intend to advance the proposition that countries disappear off the map if they don't advertize themselves? There are so many, and vastly more authentic, channels of information that I hardly think it bears comparing them with something as ignorant as travel advertizing.
Concerning expensive items that have a long usable lifetime, I'm afraid that you can't equate reputation with advertizing. Reputation is earned, not bought. Advertizing isn't even based on based on features and benefits any more, whereas assessing reputation on the other hand means exactly this, in the context of someone you know and whose judgment you have reason to trust. That person's reputation is part of the equation too. Do you seriously rely on advertizing in place of this? Would you let a stranger advise you on buying a sailboat, and not someone with whom you have sailing experience? That's absurd.
Concerning inexpensive items like wine, again reputation has nothing at all to do with advertizing. Just take a bottle home and check it out. A good wine faces no difficulty in building its reputation based on your direct personal experience. It's simply a matter of building up that experience. We do blind tastings to ensure impartiality, but among reasonably expert people there are few surprises. For ordinary purposes an educated palate is quite capable of informing your preferences, and for comparing one vintage of a wine against another and deciding which to drink up now and which to hold for a few more years. And one pattern clearly stands out: if a wine is mass marketed through advertizing, it's guaranteed to be uninteresting to anyone knowledgeable about wines. I would far rather buy a wine at random and at least have some chance of being surprised.
Please, do yourself a favor and come up with one defensible example of where advertizing creates a positive outcome for individuals and socienty. Surely there's at least one?
What a self-serving argument you have there! Advertizing is good because - let's see now - because there are products, and also coincidentally there is advertizing, so advertizing must have created the products.
You know, the reality is that the world gets along just fine in the total absence of advertizing. Speaking only for myself, someone who is a software engineer and a motorcyclist and a glassblower and a musician and a wooden boat owner and a winemaker and the owner of wilderness property where I do a fair amount of construction and fine millwork, and who also travels extensively and speaks several languages... as I say, speaking only for myself, it is simply never the case that I make a purchase based on advertising. Instead, my purchases are made the basis of (a) what I realistically need and (b) what is realistically available, meaning in essence what is available in the community.
That's the way most of the world works. If you've done much travelling, you would know this. There is a shack by the side of the road and it sells stuff. You may not need stuff, but if you do, it would be a likely place to start. That's the essential concept; it's simply elaborated on a larger scale in urban settings. As has been pointed out elsewhere in this thread, the confluence of goods for sale and a need for those goods creates something called a "market". No advertizing is required to effect a market. Simply being in a community is completely sufficient. Markets specialize and attract niche communities all by themselves.
You seem to project a strange sense of helplessness and isolation where material things are concerned. Can't you think for yourself, or find things for yourself, or ask someone in the community for directions? It's genuinely not hard, you know. In fact, it's more interesting that way. Try it some time.
Others have already challenged the validity of this statement from the consumer's point of view.
You mean others have reinforced it? Yes, I saw that. They also clarified what is commonly understood by the word "advertizing". It's neither soliciting information nor merely making it available to those who seek it. In other words, it's not a "pull" model of information exchange but a "push" model, in which information is exchanged whether the recipient wishes it or is affronted by it.
Now, as to your claim that the seller needs to be targeted by advertizing, the situation may be different in the sense that he is essentially engaged in the business of buying and selling goods for profit, therefore possibly constitutes a special case. (Ordinary people, as a category, are not. Essentially, their purpose is just to live their lives, which doesn't necessarily involve buying or selling at all.)
We can already infer that a retailer doesn't necessarily need advertizing in order to make a sale, since we have established that his customers are capable of making buying decisions all on their own. Now we have to ask: is the same capacity for buying decisions somehow not available to the retailer?
You claim the answer is yes, on the basis that trade shows and magazines are forms of advertizing. But they're not, according to the common definition. They're forms of marketing, certainly. Markets are places where buyers and sellers have agreed to come together. But this condition of mutual agreement is not the case in advertizing, and so your argument fails.
The distinction between marketing and advertizing is critical. Those who defend advertizing, on the other hand, will invariably try to claim that no such distinction exists.
You can't know to buy a product without some advertising to tell you it exists.
That's not a claim that can withstand much scrutiny. It's simply, comprehensively, untrue.
People can, and routinely do, live perfectly well without any advertizing at all. They buy things they need, having noticed a need for something. It's rarely in their interest to buy something merely because some stranger happens to tell them that they need it.
If I need groceries, I know how to visit a grocery store. If I need a box of M10x40 socket head cap screws in type 316 stainless steel, I'll go to a fastener store. From the mundane to the exotic, it's simply not a problem. No advertizing is required.
What a kind gesture that is! Saving all the stupid "average consumers" from the possibility of becoming confused by the terribly subtle distinction between (a) the ordinary raising of crops and livestock that we have been doing for many thousands of years, and (b) biochemically removing specific DNA from one organism and inserting it into another. I guess the reasoning is that, for the sake of them not becoming frustrated when reading big words, the rest of us must remain in ignorance.
Here's an observation to put your kindness into perspective. My girlfriend has a daughter who's now 27 and still living at home. Why is that? Because her measured IQ is down in the 70 range. She can't quite keep it together living on her own, and it's been an uphill battle to get assisted care for her. But she's quite comfortable with reading, and she takes great interest in the world around her.
Guess what? She has no difficulty whatever in understanding what GMOs are, and how they are distinct from organisms which arise through breeding. No problem at all.
So your fine sentiments are really, at best, only in service of the population below IQ 70. And those people can't even live on their own! Somebody more intelligent is going to be buying groceries for them. You want that somebody to be ill-informed. Why? How does that benefit anyone but the GM industry?
They have lots of awesome IP, just idiot management who seems unable to execute.
I think I can attest to this.
I'm a computer scientist who's done a lot of development over the years, as well as large-scale system and network administration. A few months ago, I responded to a job posting for a senior technical position there. The fit seemed great. The description could have been summarizing my career. I spent a whole day in job interviews at EA, having already been phone interviewed with a hiring manager and the VP of the group I'd be working in. The VP and I had gotten along great. We talked about architecture and operations and what each of us saw as emerging paradigms. Before the site visit, I'd also spent a hour answering a detailed technical questionnaire and several hours writing a programming test. (I don't regret this effort: there was an interesting problem to solve and I was quite pleased with the elegance and correctness of my solution.)
But not once in the entire day of meetings was the programming test ever mentioned, much less my technical qualifications, much less anything about the position for which I'd applied. Everybody I talked to wanted to talk about management style and politics and who reports to whom and what would I do in various hypothetical management situations. I seriously thought that they'd made a mistake and scheduled the wrong candidate that day. But no, it was a case of management seeing the world exclusively in terms of management.
Apart from that stunning aspect of cognitive disjunction, the day ran very smoothly. I don't know quite how to describe the mood. It was a bit like being at Club Med or on a cruise ship or at a Las Vegas casino. Polished, courteous, competent, friendly, and yet somehow lacking. A bit soulless, a bit careful to not do or say anything even mildly distinctive or controversial. Corporate.
No surprise, they turned me down for the position, saying they were looking for someone with more of a management orientation. Yeah, well, cool. How would like to put that somewhere in your job posting? We could have all saved ourselves a lot of time. But you see, that's exactly where EA is in trouble. There's a disconnect, and it's stratified. People at the top and in the trenches think EA is one thing, but meanwhile all the middle management are having a fine time carving out turf for themselves and sniping at each other and thinking that's reality.
I should add a comment about the term "hosted services". Yes, in principle this might do just as well. Bit I don't think it entirely captures the degree of paradigm shift that we're talking about. A hosted service is an abstract service all right. And without abstract services you can't possibly speak of a cloud implementation of anything. But I think we maintain a lingering semantic association of "hosting" a service in something physical. Maybe that feels comforting, to remember that in fact it's not turtles all the way down. But that lingering thought doesn't permit the complete separation of concerns that distinguishes cloud computing.
Much to my surprise, I've come to understand that "cloud computing" is a distinctive and legitimate term for a particular approach to managing computing resources.
It's not a consequence of any single technology, except virtualization perhaps. It's more the idea of what becomes possible at the point where you can provision, manage, use, and deprovision a practical computing environment entirely in software.
It's not that the underlying hardware doesn't exist and can't make itself felt through outages of all the usual kinds. It's that we've effected a practical separation of concerns between the virtual environment and the physical one.
It's as important, in its way, as the shift between counting actual cattle versus counting up tallies on a stick. Ultimately you still need the cows, of course, as individual beings, but abstract numbers are a lot easier to carry around with you.
It's generally not that case that from the emergence of any new possibility that you could do something, it automatically follows that you should do it.
The reasoning is akin to Cantor diagonalization. Any imperative that you should do something has to be justified, and such justification proceeds stepwise.
I'm more inclined to describe it as an inherent SMS vulnerability that one particular product happened to touch.
Will fixing the iPhone make this vulnerability go away? No. Anyone who wants to exploit it simply has to find a hackable cell phone, or engineer one for themselves.
Strange as it may seem to you, we're not all idiot consumers here on Slashdot. A reasonable operating assumption, and a courteous one, is that in our postings about software systems we're not offering a narrow viewpoint about one narrow aspect of the system but looking at it as a whole, from the perspective of a producer. That your own viewpoint may not reach to this level is no reason to project the same onto others.
Just try to be nice. Looking at your other postings, I gather that you're not very good at that, but there's no reason that you can't be. It just takes practice.
Well, let's see. There's dpkg-buildpackage. There's debuild. There's the debhelper suite. There's pbuilder. A couple of weeks ago, I ran across a fairly sophisticated Debian packager based on autoconf, but it was a huge hassle to set up.
These things all have partially-overlapping capabilities. They all pass configurations around in strange and inconsistent ways. Some use command args. Some use environment variables. Some check for the presence of certain files that may, or not, exist as a side effect of something else. Some rely on makefiles. Some invoke each other. Some only partially invoke each other but bypass certain steps.
Hmm. I find the packaging system in Debian to be frustratingly parochial. It works fine as long as you allow packages to be installed in default locations. It tends to fail badly at package relocation, something that Sun, SGI, and others got right long ago, and which RPM generally does very well also.
The problem isn't that Debian is basically a PC operating system that you can hack on. That's a worthy thing to be. The problem is people who try to use Debian in the enterprise, or for research or software development or embedded systems where software has to be installed in a multiplicity of ways. And those are exactly the areas that I work in.
I'm becoming convinced that the Debian packaging system was written by squirrels. The inconsistency of configuration and the splendid variety of side effects reminds me of buried nuts. How else do you explain that there are half a dozen packaging frameworks that all try to make the native packager more usable?
This has nothing to do with CALEA. See my synopsis above. CALEA is about packet intercept, not interpretation of the resulting packets. The language is quite clear and it says nothing whatever about encryption. Therefore there can be no "obstruction of justice" arising from encryption. Of course it's possible that future legislation could tighten the noose. CALEA can be seen as as strategic move rather than an end in itself. But in that sense, I'm surprised at how little controversy it's raised.
Meanwhile, it seems that a lot of packet interception is happening in the United States without judicial oversight. Carriers are just handing over their data. This is an extremely creepy development because of its essential lawlessness. If you want to talk about fraud or obstruction of justice, this is where it's happening. On the other hand, if the captured data turns out to be encrypted, there's even less of a case to be made of "obstruction of justice" by the subscriber. What justice would that be, exactly, if the packet capture was extrajudicial in the first place?
It isn't entirely clear whether PC-PC skype connections would be treated as part of that 'interconnected VoIP service' or whether, because they aren't directly interconnected, they are treated separately.
As someone involved with engineering a CALEA intercept appliance, I can offer a practical answer to your question.
If you operate a network under jurisdiction of the United States and you receive a court-ordered request to intercept packets transiting that network to or from an IP address or a person as identified in that court order, you must intercept those packets and only those packets, and you must make them available for retrieval by the law enforcement agency identified in the order. If you fail to do so, you're subject to a substantial fine for each day of non-compliance.
It doesn't matter what data the packets may be carrying, or whether the LEA knows how to interpret them. Your responsibility is simply to perform the packet capture and make the data available. What Microsoft thinks about this has absolutely no bearing on the problem.
"The most important thing to remember when you’re storing or processing sensitive data in the cloud is that you are still fully responsible for the security of the data, and you are fully accountable if that data is lost or stolen,” Shaul concluded. “Even if your cloud provider offers some security services or indemnifies you for losses resulting from a breach, if your data is stolen, it’s still your problem.”
This is a resounding vote for private cloud. At the very least, if you're thinking of deploying an application to a public cloud provider, better make sure that you have the cloud implementation fully operational in your own data center. Then, if you like how it works, you can incrementally migrate pieces of it to the public cloud. There may be a core component that has to remain in house for security reasons, and that's fine, that's simply being realistic.
Well said. It's worth thinking explicitly about the roles of speaker and listener as they are traded back and forth during a conversation. The person who has knowledge to impart (the speaker) is chiefly responsible for it. He has to figure out how best to communicate his idea. The person on the receiving end has responsibilities too, to listen actively and to provide feedback about how clearly the knowledge is coming across. But frankly, these are not as demanding as those of the speaker. The speaker, already having the knowledge, is in the more privileged position.
Everyone gets a turn at being speaker or listener. I'm not suggesting that there's anything unfair, just that in terms of individual elements of knowledge it's an inherently asymmetrical situation. The larger burden of responsibility falls to the speaker.
That's why grammar and spelling and so on are important. They're a way of signalling to the reader that the writer is prepared to keep up his end of the bargain. If your idea is so great that you want someone to stop and pay attention to it, show some care in how you present it.
Just because a thing is legally permitted does not make it sensible. I'm pretty sure that it's legal for me to stockpile Froot Loops by filling my car with them. Consider the EC as being advocates of that sort of thinking.
We started out with a definition of "cloud" that was mostly marketing hype. I figured that it was all smoke and mirrors. But it turns out that the market wanted this thing so badly that it has actually come true, sort of an inversion of the "build it and they will come" mantra.
Now that the concept is a bit more mature and is being treated with more architectural rigor, things are starting to get interesting. The cloud that shows up in network diagrams is now called "public cloud" and there is a structurally equivalent entity called "private cloud" which is on your private network and is managed by you. The inference that all clouds are opaque is obsolete. Get it out of your brain.
Well then, why even call the thing a "private cloud"? Isn't it the same network by a different name? No, "private cloud" means a certain class of managed application stack designed for simplicity of management, rapid automated deployment, horizontal scaling, and virtualization. That doesn't mean that any part of it is welded shut, but only that you don't have to look under the hood if you don't want to.
Actually, I'm just providing a factual data point based on fairly extensive experience. If that doesn't happen to support your confirmation bias, you should probably regard that as your problem, not mine.
Linux works fine for me as a desktop environment. I've used it in my consulting business for 14 years now, and worked at several places recently where it was the favored desktop among the technical staff.
Conversely, every time I have worked at a place where Windows was the standard desktop, it's been some ponderous old enterprise or government site, in other words a technical backwater.
Virtualization in any real scale is a cluster. HPC is a cluster. There's no need to cluster a cluster, it's pointless. Virtualization has no business in HPC, but in almost every other computing aspect it makes real sense. Especially in a world where whatever server you buy uses a small percent of the processing power that it's capable of over almost any given timeframe. Most apps or scenarios are "bursty", and that is where virtualization if done right can really excel.
Agreed on all points. Except that now I have to be pedantic and point out that HPC is the quintessence of burst utilization.
What we really have to do is to treat burst performance as two disjoint cases:
Use HPC when an explicit subdivision of work across physical resources results in sufficient performance to justify the effort.
Use virtualization when you just want a mass of resources.
of all the places you could start with slashing the costs thereof, you start with the one that most executives understand the least about
Ah, but this is exactly why the push toward cloud services is happening in the public cloud, with private cloud being almost entirely an afterthought. From the executive point of view, moving into the cloud is not a big disruption. It's just replacing one incomprehensible infrastructure run by a bunch of anonymous tech drones with another.
Now, we could argue that such a perception is utterly wrong, that complexity and reliability and security issues don't magically go away just because a new abstraction layer has been added on top of them. But we're not the ones making the money decisions.
Slashdot Mirror
You don't have very good reading skills, do you? I gave a clear explanation in the third paragraph.
However, you're welcome to celebrate your position of staunch ignorance, if that rocks your boat. Have a nice day.
A useful distinction can be made between Public Cloud and Private Cloud, and it puts the matter on firmer technical ground.
Private Cloud is when the hardware is yours. It lives inside your firewall and is subject to your security practices. Public Cloud, conversely, is not yours.
Having cleared up that detail, we can talk about what makes it a "cloud" and not just a bunch of services running who-really-cares-where. Essentially, it comes about as a consequence of virtualization. There's a qualitative difference between saying, "I need to buy a server with X capacity in order to run my application," and creating an instance of your application in a cloud. Yes, they both ultimately depend on hardware capacity, but there is a separation of concerns between the abstract resources that your app needs and how they are physically provided. You tend not to think about servers any more but about instances of things. It encourages a more modular, more fluid way of solving problems.
For example, I've been talking with one of my colleagues this week about setting up a package repository. That's a server which delivers software packages for clients to install. New packages have to be added to the repository automatically, and they have to be signed. Now, this raises the awkward question of where to maintain the private key used for signing each change to the repository. We found ourselves having to rule out all of the possible algorithmic options. The essential requirement is that the signing has to be encapsulated inside something that can peform computations. What we really need is a specially hardened server that does nothing but sign changes to the repo. But who can afford to buy a whole server just for that one narrow purpose? If the server is virtual, the resource issue goes away.
Of course, other issues remain. Just as there is an inherent security risk in having unrestricted access to a physical server, there is risk in having comparable access to a virtual server. In principle, disaster recovery in a virtualized environment ought to be more robust than in a physical one, because you can maintain a perfect digital record of everything that went into creating that environment. But even if you keep that record offsite in multiple bank vaults, if you have never tried to actually bring up and test a virtual environment with it, you may be in for a big surprise.
So I don't want to do what the marketing people do and say that cloud solutions are magically wonderful. There's a useful separation of concerns in a cloud solution that, I believe, leads to a more elegant way of approaching design problems. And there's a big difference between private and public cloud that the people selling public cloud services don't really like to talk about. As to whether a cloud solution has specific advantages for you, I think one of the most surprising results is that it comes with a change of thinking.
Uh huh. Yeah, almost.
This is an absurd discussion. I feel like I'm talking with a creationist. Can't you make even one valid point? Please?
Please, do yourself a favor and come up with one defensible example of where advertizing creates a positive outcome for individuals and socienty. Surely there's at least one?
What a self-serving argument you have there! Advertizing is good because - let's see now - because there are products, and also coincidentally there is advertizing, so advertizing must have created the products.
You know, the reality is that the world gets along just fine in the total absence of advertizing. Speaking only for myself, someone who is a software engineer and a motorcyclist and a glassblower and a musician and a wooden boat owner and a winemaker and the owner of wilderness property where I do a fair amount of construction and fine millwork, and who also travels extensively and speaks several languages... as I say, speaking only for myself, it is simply never the case that I make a purchase based on advertising. Instead, my purchases are made the basis of (a) what I realistically need and (b) what is realistically available, meaning in essence what is available in the community.
That's the way most of the world works. If you've done much travelling, you would know this. There is a shack by the side of the road and it sells stuff. You may not need stuff, but if you do, it would be a likely place to start. That's the essential concept; it's simply elaborated on a larger scale in urban settings. As has been pointed out elsewhere in this thread, the confluence of goods for sale and a need for those goods creates something called a "market". No advertizing is required to effect a market. Simply being in a community is completely sufficient. Markets specialize and attract niche communities all by themselves.
You seem to project a strange sense of helplessness and isolation where material things are concerned. Can't you think for yourself, or find things for yourself, or ask someone in the community for directions? It's genuinely not hard, you know. In fact, it's more interesting that way. Try it some time.
Others have already challenged the validity of this statement from the consumer's point of view.
You mean others have reinforced it? Yes, I saw that. They also clarified what is commonly understood by the word "advertizing". It's neither soliciting information nor merely making it available to those who seek it. In other words, it's not a "pull" model of information exchange but a "push" model, in which information is exchanged whether the recipient wishes it or is affronted by it.
Now, as to your claim that the seller needs to be targeted by advertizing, the situation may be different in the sense that he is essentially engaged in the business of buying and selling goods for profit, therefore possibly constitutes a special case. (Ordinary people, as a category, are not. Essentially, their purpose is just to live their lives, which doesn't necessarily involve buying or selling at all.)
We can already infer that a retailer doesn't necessarily need advertizing in order to make a sale, since we have established that his customers are capable of making buying decisions all on their own. Now we have to ask: is the same capacity for buying decisions somehow not available to the retailer?
You claim the answer is yes, on the basis that trade shows and magazines are forms of advertizing. But they're not, according to the common definition. They're forms of marketing, certainly. Markets are places where buyers and sellers have agreed to come together. But this condition of mutual agreement is not the case in advertizing, and so your argument fails.
The distinction between marketing and advertizing is critical. Those who defend advertizing, on the other hand, will invariably try to claim that no such distinction exists.
You can't know to buy a product without some advertising to tell you it exists.
That's not a claim that can withstand much scrutiny. It's simply, comprehensively, untrue.
People can, and routinely do, live perfectly well without any advertizing at all. They buy things they need, having noticed a need for something. It's rarely in their interest to buy something merely because some stranger happens to tell them that they need it.
If I need groceries, I know how to visit a grocery store. If I need a box of M10x40 socket head cap screws in type 316 stainless steel, I'll go to a fastener store. From the mundane to the exotic, it's simply not a problem. No advertizing is required.
What a kind gesture that is! Saving all the stupid "average consumers" from the possibility of becoming confused by the terribly subtle distinction between (a) the ordinary raising of crops and livestock that we have been doing for many thousands of years, and (b) biochemically removing specific DNA from one organism and inserting it into another. I guess the reasoning is that, for the sake of them not becoming frustrated when reading big words, the rest of us must remain in ignorance.
Here's an observation to put your kindness into perspective. My girlfriend has a daughter who's now 27 and still living at home. Why is that? Because her measured IQ is down in the 70 range. She can't quite keep it together living on her own, and it's been an uphill battle to get assisted care for her. But she's quite comfortable with reading, and she takes great interest in the world around her.
Guess what? She has no difficulty whatever in understanding what GMOs are, and how they are distinct from organisms which arise through breeding. No problem at all.
So your fine sentiments are really, at best, only in service of the population below IQ 70. And those people can't even live on their own! Somebody more intelligent is going to be buying groceries for them. You want that somebody to be ill-informed. Why? How does that benefit anyone but the GM industry?
They have lots of awesome IP, just idiot management who seems unable to execute.
I think I can attest to this.
I'm a computer scientist who's done a lot of development over the years, as well as large-scale system and network administration. A few months ago, I responded to a job posting for a senior technical position there. The fit seemed great. The description could have been summarizing my career. I spent a whole day in job interviews at EA, having already been phone interviewed with a hiring manager and the VP of the group I'd be working in. The VP and I had gotten along great. We talked about architecture and operations and what each of us saw as emerging paradigms. Before the site visit, I'd also spent a hour answering a detailed technical questionnaire and several hours writing a programming test. (I don't regret this effort: there was an interesting problem to solve and I was quite pleased with the elegance and correctness of my solution.)
But not once in the entire day of meetings was the programming test ever mentioned, much less my technical qualifications, much less anything about the position for which I'd applied. Everybody I talked to wanted to talk about management style and politics and who reports to whom and what would I do in various hypothetical management situations. I seriously thought that they'd made a mistake and scheduled the wrong candidate that day. But no, it was a case of management seeing the world exclusively in terms of management.
Apart from that stunning aspect of cognitive disjunction, the day ran very smoothly. I don't know quite how to describe the mood. It was a bit like being at Club Med or on a cruise ship or at a Las Vegas casino. Polished, courteous, competent, friendly, and yet somehow lacking. A bit soulless, a bit careful to not do or say anything even mildly distinctive or controversial. Corporate.
No surprise, they turned me down for the position, saying they were looking for someone with more of a management orientation. Yeah, well, cool. How would like to put that somewhere in your job posting? We could have all saved ourselves a lot of time. But you see, that's exactly where EA is in trouble. There's a disconnect, and it's stratified. People at the top and in the trenches think EA is one thing, but meanwhile all the middle management are having a fine time carving out turf for themselves and sniping at each other and thinking that's reality.
I should add a comment about the term "hosted services". Yes, in principle this might do just as well. Bit I don't think it entirely captures the degree of paradigm shift that we're talking about. A hosted service is an abstract service all right. And without abstract services you can't possibly speak of a cloud implementation of anything. But I think we maintain a lingering semantic association of "hosting" a service in something physical. Maybe that feels comforting, to remember that in fact it's not turtles all the way down. But that lingering thought doesn't permit the complete separation of concerns that distinguishes cloud computing.
Much to my surprise, I've come to understand that "cloud computing" is a distinctive and legitimate term for a particular approach to managing computing resources.
It's not a consequence of any single technology, except virtualization perhaps. It's more the idea of what becomes possible at the point where you can provision, manage, use, and deprovision a practical computing environment entirely in software.
It's not that the underlying hardware doesn't exist and can't make itself felt through outages of all the usual kinds. It's that we've effected a practical separation of concerns between the virtual environment and the physical one.
It's as important, in its way, as the shift between counting actual cattle versus counting up tallies on a stick. Ultimately you still need the cows, of course, as individual beings, but abstract numbers are a lot easier to carry around with you.
It's generally not that case that from the emergence of any new possibility that you could do something, it automatically follows that you should do it.
The reasoning is akin to Cantor diagonalization. Any imperative that you should do something has to be justified, and such justification proceeds stepwise.
I'm more inclined to describe it as an inherent SMS vulnerability that one particular product happened to touch.
Will fixing the iPhone make this vulnerability go away? No. Anyone who wants to exploit it simply has to find a hackable cell phone, or engineer one for themselves.
Condescension doesn't help yours.
Strange as it may seem to you, we're not all idiot consumers here on Slashdot. A reasonable operating assumption, and a courteous one, is that in our postings about software systems we're not offering a narrow viewpoint about one narrow aspect of the system but looking at it as a whole, from the perspective of a producer. That your own viewpoint may not reach to this level is no reason to project the same onto others.
Just try to be nice. Looking at your other postings, I gather that you're not very good at that, but there's no reason that you can't be. It just takes practice.
Well, let's see. There's dpkg-buildpackage. There's debuild. There's the debhelper suite. There's pbuilder. A couple of weeks ago, I ran across a fairly sophisticated Debian packager based on autoconf, but it was a huge hassle to set up.
These things all have partially-overlapping capabilities. They all pass configurations around in strange and inconsistent ways. Some use command args. Some use environment variables. Some check for the presence of certain files that may, or not, exist as a side effect of something else. Some rely on makefiles. Some invoke each other. Some only partially invoke each other but bypass certain steps.
Hmm. I find the packaging system in Debian to be frustratingly parochial. It works fine as long as you allow packages to be installed in default locations. It tends to fail badly at package relocation, something that Sun, SGI, and others got right long ago, and which RPM generally does very well also.
The problem isn't that Debian is basically a PC operating system that you can hack on. That's a worthy thing to be. The problem is people who try to use Debian in the enterprise, or for research or software development or embedded systems where software has to be installed in a multiplicity of ways. And those are exactly the areas that I work in.
I'm becoming convinced that the Debian packaging system was written by squirrels. The inconsistency of configuration and the splendid variety of side effects reminds me of buried nuts. How else do you explain that there are half a dozen packaging frameworks that all try to make the native packager more usable?
This has nothing to do with CALEA. See my synopsis above. CALEA is about packet intercept, not interpretation of the resulting packets. The language is quite clear and it says nothing whatever about encryption. Therefore there can be no "obstruction of justice" arising from encryption. Of course it's possible that future legislation could tighten the noose. CALEA can be seen as as strategic move rather than an end in itself. But in that sense, I'm surprised at how little controversy it's raised.
Meanwhile, it seems that a lot of packet interception is happening in the United States without judicial oversight. Carriers are just handing over their data. This is an extremely creepy development because of its essential lawlessness. If you want to talk about fraud or obstruction of justice, this is where it's happening. On the other hand, if the captured data turns out to be encrypted, there's even less of a case to be made of "obstruction of justice" by the subscriber. What justice would that be, exactly, if the packet capture was extrajudicial in the first place?
It isn't entirely clear whether PC-PC skype connections would be treated as part of that 'interconnected VoIP service' or whether, because they aren't directly interconnected, they are treated separately.
As someone involved with engineering a CALEA intercept appliance, I can offer a practical answer to your question. If you operate a network under jurisdiction of the United States and you receive a court-ordered request to intercept packets transiting that network to or from an IP address or a person as identified in that court order, you must intercept those packets and only those packets, and you must make them available for retrieval by the law enforcement agency identified in the order. If you fail to do so, you're subject to a substantial fine for each day of non-compliance.
It doesn't matter what data the packets may be carrying, or whether the LEA knows how to interpret them. Your responsibility is simply to perform the packet capture and make the data available. What Microsoft thinks about this has absolutely no bearing on the problem.
"The most important thing to remember when you’re storing or processing sensitive data in the cloud is that you are still fully responsible for the security of the data, and you are fully accountable if that data is lost or stolen,” Shaul concluded. “Even if your cloud provider offers some security services or indemnifies you for losses resulting from a breach, if your data is stolen, it’s still your problem.”
This is a resounding vote for private cloud. At the very least, if you're thinking of deploying an application to a public cloud provider, better make sure that you have the cloud implementation fully operational in your own data center. Then, if you like how it works, you can incrementally migrate pieces of it to the public cloud. There may be a core component that has to remain in house for security reasons, and that's fine, that's simply being realistic.
Well said. It's worth thinking explicitly about the roles of speaker and listener as they are traded back and forth during a conversation. The person who has knowledge to impart (the speaker) is chiefly responsible for it. He has to figure out how best to communicate his idea. The person on the receiving end has responsibilities too, to listen actively and to provide feedback about how clearly the knowledge is coming across. But frankly, these are not as demanding as those of the speaker. The speaker, already having the knowledge, is in the more privileged position.
Everyone gets a turn at being speaker or listener. I'm not suggesting that there's anything unfair, just that in terms of individual elements of knowledge it's an inherently asymmetrical situation. The larger burden of responsibility falls to the speaker.
That's why grammar and spelling and so on are important. They're a way of signalling to the reader that the writer is prepared to keep up his end of the bargain. If your idea is so great that you want someone to stop and pay attention to it, show some care in how you present it.
Just because a thing is legally permitted does not make it sensible. I'm pretty sure that it's legal for me to stockpile Froot Loops by filling my car with them. Consider the EC as being advocates of that sort of thinking.
We started out with a definition of "cloud" that was mostly marketing hype. I figured that it was all smoke and mirrors. But it turns out that the market wanted this thing so badly that it has actually come true, sort of an inversion of the "build it and they will come" mantra.
Now that the concept is a bit more mature and is being treated with more architectural rigor, things are starting to get interesting. The cloud that shows up in network diagrams is now called "public cloud" and there is a structurally equivalent entity called "private cloud" which is on your private network and is managed by you. The inference that all clouds are opaque is obsolete. Get it out of your brain.
Well then, why even call the thing a "private cloud"? Isn't it the same network by a different name? No, "private cloud" means a certain class of managed application stack designed for simplicity of management, rapid automated deployment, horizontal scaling, and virtualization. That doesn't mean that any part of it is welded shut, but only that you don't have to look under the hood if you don't want to.
Actually, I'm just providing a factual data point based on fairly extensive experience. If that doesn't happen to support your confirmation bias, you should probably regard that as your problem, not mine.
Linux works fine for me as a desktop environment. I've used it in my consulting business for 14 years now, and worked at several places recently where it was the favored desktop among the technical staff.
Conversely, every time I have worked at a place where Windows was the standard desktop, it's been some ponderous old enterprise or government site, in other words a technical backwater.
Virtualization in any real scale is a cluster. HPC is a cluster. There's no need to cluster a cluster, it's pointless. Virtualization has no business in HPC, but in almost every other computing aspect it makes real sense. Especially in a world where whatever server you buy uses a small percent of the processing power that it's capable of over almost any given timeframe. Most apps or scenarios are "bursty", and that is where virtualization if done right can really excel.
Agreed on all points. Except that now I have to be pedantic and point out that HPC is the quintessence of burst utilization.
What we really have to do is to treat burst performance as two disjoint cases:
Ah, but this is exactly why the push toward cloud services is happening in the public cloud, with private cloud being almost entirely an afterthought. From the executive point of view, moving into the cloud is not a big disruption. It's just replacing one incomprehensible infrastructure run by a bunch of anonymous tech drones with another.
Now, we could argue that such a perception is utterly wrong, that complexity and reliability and security issues don't magically go away just because a new abstraction layer has been added on top of them. But we're not the ones making the money decisions.