What different behavior would you prefer in a subset browser suitable only for "web pages"? And where should one draw the line between a "web page" and a "web application"?
Figure out what subset of scripting and data caching you can build into the browser without allowing privacy/security vulnerabilities, and set that as the limit for the "web browser" so that we'll all know our web browsing is safe. If that hamstrings your web application too much, then sorry, build an application.
OpenStack is more about virtualisation than anything else. Its potential usefulness for "cloud" service providers is one example, but it's probably of more interest to large organisations looking to consolidate their own in-house IT services.
I'm not sure that's true. From what I've read (but admittedly I haven't tried to implement OpenStack), it doesn't seem to offer any great virtualization capabilities compared with other hypervisors. It seems that the benefit of OpenStack comes from it being an easy way to deploy virtualization, storage, and compute nodes as a platform for development.
If I want to set up a single server with a hypervisor, would I set up OpenStack? If I had 5 servers that I wanted to set up as hypervisors, would OpenStack make it easier to manage those systems? My impression is that, no, it wouldn't. My impression, which could be wrong, is that it only makes sense if I were creating a large-scale scalable app, designed specifically for this kind of distributed computing among a bunch of nodes, that would make it desireable to be able to provision and deploy additional nodes quickly and easily, And when I say, "quickly and easily", I mean that a good developer would find it relatively quick and easy, though for mere mortals it might be a huge pain.
Just to point this out, the onesies only existed for a short time in TNG. Later on, their uniforms actually were separate pieces, consisting of black pants and a tunic, which is why the "Picard Maneuver" was necessary.
That aside, I think there was some tension at times about the nature of the Federation and Starfleet. On its face, it was somewhat utopian-- money and poverty were abolished and people were more free to pursue the activities that they'd like. On the other hand, it's a world ruled by a vast paramilitary organization. It seems sort of fascist at times.
I think this was largely ignored for a long time. There were some misguided individuals within the Federation, but it was usually treated as though it were an almost perfect benevolent organization that protected large portions of our quadrant of the galaxy. As far as I recall, it wasn't until Section 31 comes up in DS9 that the idea of corruption within the Federation was explored.
The worst of it was that he broke what is at the heart of the franchise: that it's a story that attempts to envision what a utopian society might look like.
I kind of agree with you, but I would re-frame it in a way that I think is not quite so bad. The thing is, his Star Trek reboot and sequel are fun space-adventure movies, which is great, but the movies are not what many fans were hoping for. The old series and movies were not just fun. When the stories were good, they were nerdy and philosophical. There was action and fighting and that kind of thing, but the action took place in the middle of a fairly dry, intellectual social critique. Abrams too the components of those dry scifi stories and retooled them into a somewhat mindless fantasy/adventure movie. Many people enjoyed them, but many fans weren't entirely satisfied.
With Star Wars, on the other hand, the original stories were already inconsistent fantasy/adventure movies. So it's possible that he'll do a great job.
Personally, I'm of the opinion that we should have two different apps: One for development of relatively passive "web pages", perhaps with limited capabilities, but very secure, and then another built to be a portable application framework for "web apps". I think it's kind of great the way Chrome now allows you to have apps that seem like separate native applications, but does all of that functionality need to be tied directly to my normal web browser?
Ultimately, it boils down to this: Most of the time, I want very basic web browser functionality. Whenever that's the case, any extra capabilities you offer to access local file storage, cache persistent data, or run complex code just ends up being a security risk. Then when I want a more serious "web app", I would usually prefer that it appears separately, as its own window. So even if my web pages and my web applications are relying on the same technologies (e.g. HTTP, HTML, CSS, Javascript), I'm using them differently and I would prefer that they behave differently. So why must it be that the same web-browser application does both? Why not create a highly efficient cross-platform application framework based on those technologies, and keep the browser simple?
Sure, but you're still talking about development. Like I said, I'm not a developer, just an IT guy. What am I going to use it for?
Most companies don't run on web development. Even when they have a considerable network, the network is providing authentication/directory services (e.g. Active Directory), DNS, DHCP, file services, and maybe a few relatively small server-side apps (e.g. Quickbooks). How does OpenStack help me with any of that? Can I deploy or manage those services better or easier than setting up some instances of Windows virtual machines on a normal hypervisor?
I'm not sure what they mean by "end users". I've been keeping an eye on OpenStack, and it seems to be useful for developing cloud applications, but I might be missing the point a little. So are we calling developers of large-scale applications "end users"?
I don't think people are ignoring it, but as far as I know, OpenStack doesn't really service your standard network IT market yet, and it's not really something that will service "end users" as I think of them. It seems to be something to provide scalability for development, but if you're a developer working on a large application, it's often smarter to go with a vendor rather than trying to build your own infrastructure. That means that they go with AWS or Rackspace or something.
So my question is, who do you expect to be implementing OpenStack other than cloud providers (e.g. Rackspace) and a relatively small number of companies looking to build their own cloud infrastructure?
As an IT guy (not a developer), the whole thing is still pretty unclear. What would I use OpenStack for? If I wanted to test it out, what would I need to get started? How would I set it up? What, then could I do with it? Most of the appeal of "the cloud" at this point is the potential to divest myself of responsibility for its maintenance. The only people that I can imagine making use of OpenStack are large companies with large public, business critical web applications, and even then only those who, for whatever reason, don't want to use AWS or Rackspace or some other vendor, and have the resources to build and maintain a bunch of cloud infrastructure. Yes, there are businesses that fit that description, but it's not a large percentage of businesses.
When he says that robots aren't "competent", I don't think that he's saying that they can't do things. He's just pointing out they they only do certain specific things that they've been told to do, even if they do those things extremely well.
I think the example used points this out: The question is asked, "If the robotic car be put in the position of killing 1 person in order to save 2 people, how should it make the decision?" He's saying that there's a problem with the question, which is the assumption that the robot will be capable of understanding such a scenario.
With our current engineering techniques, we can't expect the robot to understand what it's doing, nor the moral implications. We can't program it to actually understand whether it will kill people. The most we can program it to do is, given a detection of some heuristic value, follow a certain protocol of instructions. So for example, if the robotic car can detect that it's about to hit someone, try to stop. If it calculates that it will be unable to stop, try to swerve. You might program it to detect people specifically and place extra priority on swerving around them, e.g. "if you're about to hit something identified as a person, or hit a road sign, choose to hit the road sign". We might even get it to do something like, "If you're losing control and you can detect several people, and you can't avoid the whole crowd, swerve into the sparsest area of the crowd while slowing as much as possible.
The engineers should try to anticipate these kinds of things. We as citizens should also debate about how we'd want these kinds of instructions should work to avoid legal liability. For example, we might say that in order for the AI to be legal, it must show that it will stop the car when [event x] happens. But to ask, "how will the car make moral decisions?" fundamentally misunderstands its decision-making capabilities. The answer is, "It won't make moral decisions at all."
You're conflating a lot of different issues. First, video calls are notoriously painful for various reasons. So let's just get that out of the way: it wouldn't be weird if you were having lots of problems with Skype, too.
Second, there's nothing inherently inferior about "open". If Skype were to publish a spec for how they negotiate video calls, then suddenly we have an open protocol that's as good as Skype. It's not suddenly worse because it's "open".
Third, there's a difference between a "protocol" and a "platform". It seems you're talking about having tried different pieces of free software, and had problems with them. The problems might have had nothing to do with the protocol. It might be that the software is bad. I don't know, because I don't know what problems you've had on which platforms.
We use "open standards" all the time. It's silly to suggest that open protocols don't work. How are you posting on this website? I'm guessing you're making some use of HTTP.
So law enforcement budgets will be lower, but the need for law enforcement will also be lower because you won't have to pay as many cops to run around patrolling the roads and writing tickets. Plus there will be fewer injuries and less property damage due to reckless driving, which means less economic waste.
If law enforcement legitimately needs more money, then raise taxes and pay for it. People keep talking like it's bad for the economy to permanently address problems because we'll have fewer jobs consisting of temporarily patching those problems. It's just another variation on the "broken window fallacy".
I actually think there's a bit of a cultural problem in the tech community, in that the issue of "openness" has become polarized. On one side, you have people who think openness absolutely doesn't matter, and they seem to have no problem with the "walled gardens". On the other side, you have FOSS advocates who seem to have a militant agenda to replace everything with Debian.
I would take the position that closed source software is fine, and in fact, it's good to have a diverse software ecosystem with different developers taking different approaches, open and closed source both. However, I think we should push a militant agenda for open formats and open protocols.
For example, if Google wants to have their own closed-source Hangouts app, and Facebook wants their Messenger app, and Pidgin wants to produce an open source messaging app, that's all fine. That's great, in fact. However, we should try to get them to round everyone up and agree on messaging protocols that allow users of one IM platform to communicate with users of another platform.
The equivalent for email would be if we all lived in a world where Gmail users could only email other Gmail users, and Hotmail users could only email other Hotmail users. I'm just saying, let's go ahead and develop something like SMTP so that they can talk to each other.
They never really explained why federation wouldn't work or why XMPP wasn't sufficient for their needs.
I'm not asserting that was why they did it. I'm just saying that I could understand if that was why.
It may be that if you could talk to the decision-maker inside of Google who made this decision, they'd tell you that XMPP is somehow inefficient, or it didn't offer features that they wanted. They might say that XMPP is poorly architected or something, and we might debate about whether their explanation made sense.
What I'm saying is that, if there's some technical explanation like that, then I don't object to the decision per se. However, then I would want to argue that Google should either fix it or offer a better alternative. IM, voice, and even video chats are such well understood problems at this point, that I don't believe there's a valid reason why there can't be open protocols that are shared among Hangouts, Facebook, Skype, AOL, and iMessage.
I'm not talking about taking away your choice to be in a walled garden. I haven't suggested any method to stop you from logging onto Facebook and only using Facebook.
But going with that example, I'm just suggesting that, as more and more of our communications get rammed into Facebook, and if Facebook doesn't have protocols to connect without outside systems, we're going to have a problem.
You know, I can understand why Google might decide that XMPP isn't sufficient for the kinds of features they'd like to support, and so deciding to develop something new in-house with their desired feature set. I really wish, though, they they would open a protocol that still allowed outside people to communicate.
I just find it insane how much we're moving back in the direction of "walled gardens" everywhere. There was a time when most people's exposure to online interaction were services like Compuserve, AOL, and Prodigy, and those services couldn't talk to each other. I think we're headed back in that direction, except that soon we'll all be on services like Google+, Facebook, and Twitter, and those services won't talk to each other.
We really need a revolution soon, or I think we're going to find that we don't like where we end up. I know it sounds trivial because these are all free services, and most of what's communicated on them is trivial anyway. Still, it's transforming the Internet into a less free place, where we're all at the whim of a small handful of companies. I think it's a bigger problem than we've yet realized.
This is a really good point. Current CPUs have billions of cycles per second, but still struggle to perform some tasks in real-time, and that processing is not going to be powerful enough to emulated intelligence to the degree of consciousness. If past computing problems are any indication, I would guess that the first generation of AI will be a bit "slow on the uptake". That is to say, we may come up with the algorithms to emulate consciousness first, and then need to spend some time optimizing code and improving hardware designs in order to get "real time" consciousness.
I think it's important to keep in mind that there's a point at which "more security" stops making sense and "more insurance" becomes a better option. I've had clients get overly-obsessed with security, trying to buy software that can locate/control your lost/stolen items remotely, locking everything down for physical security, etc. Then when they look at the project to secure everything, I point out that it'd be easier to insure everything instead. Along with everything else, there's no perfect security. You could go through all the effort and expense of securing things, and it could still get stolen.
Aside from that, consider whether you can just reinforce security around a closet and lock everything in there. And then train people to arm the house alarm before leaving. Even the most secure door isn't going to keep your house secure if people keep propping it open.
I don't find your explanation very clear. I understand that if, in this scenario, someone else gets 301-555-1234 and associates that number with their own iMessage account, that the messages will then be routed to their account. Also, if I set up my iMessage account to be associated with a new number, I believe it drops the old one. But what if they don't sign up for iMessage, and I don't get a new cell phone?
Because it seems to be that for each iMessage account, Apple stores a phone number for the cell phone, and then a set of email addresses. You can then address messages to either the phone number or the email address, and it gets delivered to the recipient. So if Apple isn't notified in any way that the phone number has been changed, wouldn't they keep routing messages to the old account? And then, wouldn't I still be able to receive those messages on my computer or iPad, even though I didn't have that phone number anymore?
I believe that's what happens if the sending phone can't send through iMessage, but it doesn't necessarily address what happens if the receiving phone doesn't receive the message.
Essentially you can set your iPhone to register your phone number to an iMessage account, which you can think of like an email account. So once you've registered your number, when an iPhone has a data connection, it will send the text message to this "email account" rather than sending it via SMS, even if the receiving iPhone is offline. If the sending iPhone doesn't have a data connection, it will failover to using SMS, but when it sends the message, it can't determine whether the receiving iPhone has a data connection. So even if you turn your phone off, it will send the message to this "email account" in lieu of SMS, and those messages can then be accessed on a Mac or iOS device.
So I imagine that the problem boils down to this: When you switch to using an iPhone and set up iMessage, you're notifying Apple that they can route your text messages through their "email server" instead of SMS, so they start doing that. When you switch away from using an iPhone, there isn't necessarily anything to notify Apple to stop routing text messages to the "email server", so they keep doing it. You could manually deauthorize iMessage from your phone number, but people might not remember to do that.
What seems potentially more troubling-- and I don't know if it's happened-- is the prospect that this could happen with an abandoned phone number. So imagine I have an iPhone and my phone number is 301-555-1234. I register that phone number to iMessage, so Apple begins routing text messages from iPhone users to iMessage. I then decide that I don't want a cell phone anymore, so I cancel my service and abandon the phone number. Then someone else gets a new cell phone and they are assigned the phone number 301-555-1234, but their phone is not an iPhone. Is there anything to tell Apple to stop routing that person's text messages to my iMessage account?
Yes, there are concerns about reliability on a day-to-day level, as well as the question of "Will this service be around in 3 years?" And related: "How much money are we going to spend transitioning to a service that might not be around in 3 years, and then how much money will we spend transitioning off if it goes away or we don't like it?"
But there are more problems than that: in some contexts, the "Cloud" services just aren't as good. If my "network" is made up of a bunch of laptops traveling throughout the country, then a "cloud" file sharing service like Dropbox might be very handy. If, however, my network is a LAN with a bunch of workstations hard-lined into it, and I have 5 TB of files stored on a file server, then moving that file server to Dropbox might not offer any improvement at all. If I'm managing those workstations with a Windows domain to provide group policies and single sign-on, there isn't a cloud service that I'm aware of that provides the same functionality as simply and elegantly. You also have to consider which model serves users better when the Internet is down or slow. If everything is on the Internet, then when the Internet goes out, your business is shut down.
So I don't know who Curtis Peterson is, when people start talking derisively about the use of local servers, I usually guess that they've never done real IT work. There are still a lot of situations where you need too much control, too much security, and too much bandwidth to push it all offsite-- regardless of whether you call it "the cloud" or "a hosted server" or "a collocated server". As an IT guy, I'd love to move everything to "the cloud", but it's not ready. And it won't be ready until we (a) have ubiquitous, high speed, highly reliable Internet everywhere; and (b) the "cloud" becomes more built on open formats, APIs and protocols rather than having a bunch of big businesses pushing us into little walled gardens.
I'd imagine that nobody has come up with an assassination robot because of the need for stealth. It'd be hard enough to have a robot target a specific individual, but to do it without alerting anyone ahead of time would be much trickier. I would think that poison or a bomb would be easier.
Now if you're talking about a cruise missile, then I'm not sure what's gained by having it be completely autonomous. You may as well have someone sitting in a bunker someplace selecting the target and deciding whether to fire it, and then having appropriate computerized guidance.
Yeah, I always find it funny when people cite the "3 laws" as though they were brilliant fail-safe mechanisms that we should of course put into robots in reality. Did nobody actually read Asimov's stories? They're a catalog of examples of how the 3 laws would fail, or at least of how they'd be too ambiguous.
Beyond that, I see another problem with the idea of banning development of autonomous weapons: most of the technology involved would probably be developed anyway because it would be widely applicable.
Think about it. If you were going to make a killer robotic soldier, what technology would be hard to develop? It's difficult to make a robot that can easily traverse diverse terrain, but we'll work on that for other reasons. Making an AI that can accurately identify people by facial features, clothing, and speech patterns would be hard. We'd also do that for other reasons. There are a million reasons to develop and intelligent free-roaming robot who can identify people and interact with them.
Once you have a robot that can do those kinds of things, turning the "interaction" into "fire a weapon at that person" is easy. It's not hard for a computer to aim once it has its target. It's not hard for a computer to trigger the weapon itself.
Good point. I suspect that when people hear the term "cyber-terrorism", somewhere in their subconscious or unconscious, they imagine terminator-like cyborgs with bombs strapped to their chests. Or something like that.
What different behavior would you prefer in a subset browser suitable only for "web pages"? And where should one draw the line between a "web page" and a "web application"?
Figure out what subset of scripting and data caching you can build into the browser without allowing privacy/security vulnerabilities, and set that as the limit for the "web browser" so that we'll all know our web browsing is safe. If that hamstrings your web application too much, then sorry, build an application.
OpenStack is more about virtualisation than anything else. Its potential usefulness for "cloud" service providers is one example, but it's probably of more interest to large organisations looking to consolidate their own in-house IT services.
I'm not sure that's true. From what I've read (but admittedly I haven't tried to implement OpenStack), it doesn't seem to offer any great virtualization capabilities compared with other hypervisors. It seems that the benefit of OpenStack comes from it being an easy way to deploy virtualization, storage, and compute nodes as a platform for development.
If I want to set up a single server with a hypervisor, would I set up OpenStack? If I had 5 servers that I wanted to set up as hypervisors, would OpenStack make it easier to manage those systems? My impression is that, no, it wouldn't. My impression, which could be wrong, is that it only makes sense if I were creating a large-scale scalable app, designed specifically for this kind of distributed computing among a bunch of nodes, that would make it desireable to be able to provision and deploy additional nodes quickly and easily, And when I say, "quickly and easily", I mean that a good developer would find it relatively quick and easy, though for mere mortals it might be a huge pain.
Just to point this out, the onesies only existed for a short time in TNG. Later on, their uniforms actually were separate pieces, consisting of black pants and a tunic, which is why the "Picard Maneuver" was necessary.
That aside, I think there was some tension at times about the nature of the Federation and Starfleet. On its face, it was somewhat utopian-- money and poverty were abolished and people were more free to pursue the activities that they'd like. On the other hand, it's a world ruled by a vast paramilitary organization. It seems sort of fascist at times.
I think this was largely ignored for a long time. There were some misguided individuals within the Federation, but it was usually treated as though it were an almost perfect benevolent organization that protected large portions of our quadrant of the galaxy. As far as I recall, it wasn't until Section 31 comes up in DS9 that the idea of corruption within the Federation was explored.
The worst of it was that he broke what is at the heart of the franchise: that it's a story that attempts to envision what a utopian society might look like.
I kind of agree with you, but I would re-frame it in a way that I think is not quite so bad. The thing is, his Star Trek reboot and sequel are fun space-adventure movies, which is great, but the movies are not what many fans were hoping for. The old series and movies were not just fun. When the stories were good, they were nerdy and philosophical. There was action and fighting and that kind of thing, but the action took place in the middle of a fairly dry, intellectual social critique. Abrams too the components of those dry scifi stories and retooled them into a somewhat mindless fantasy/adventure movie. Many people enjoyed them, but many fans weren't entirely satisfied.
With Star Wars, on the other hand, the original stories were already inconsistent fantasy/adventure movies. So it's possible that he'll do a great job.
Personally, I'm of the opinion that we should have two different apps: One for development of relatively passive "web pages", perhaps with limited capabilities, but very secure, and then another built to be a portable application framework for "web apps". I think it's kind of great the way Chrome now allows you to have apps that seem like separate native applications, but does all of that functionality need to be tied directly to my normal web browser?
Ultimately, it boils down to this: Most of the time, I want very basic web browser functionality. Whenever that's the case, any extra capabilities you offer to access local file storage, cache persistent data, or run complex code just ends up being a security risk. Then when I want a more serious "web app", I would usually prefer that it appears separately, as its own window. So even if my web pages and my web applications are relying on the same technologies (e.g. HTTP, HTML, CSS, Javascript), I'm using them differently and I would prefer that they behave differently. So why must it be that the same web-browser application does both? Why not create a highly efficient cross-platform application framework based on those technologies, and keep the browser simple?
Sure, but you're still talking about development. Like I said, I'm not a developer, just an IT guy. What am I going to use it for?
Most companies don't run on web development. Even when they have a considerable network, the network is providing authentication/directory services (e.g. Active Directory), DNS, DHCP, file services, and maybe a few relatively small server-side apps (e.g. Quickbooks). How does OpenStack help me with any of that? Can I deploy or manage those services better or easier than setting up some instances of Windows virtual machines on a normal hypervisor?
If so, please let me know how. I'm interested.
I'm not sure what they mean by "end users". I've been keeping an eye on OpenStack, and it seems to be useful for developing cloud applications, but I might be missing the point a little. So are we calling developers of large-scale applications "end users"?
I don't think people are ignoring it, but as far as I know, OpenStack doesn't really service your standard network IT market yet, and it's not really something that will service "end users" as I think of them. It seems to be something to provide scalability for development, but if you're a developer working on a large application, it's often smarter to go with a vendor rather than trying to build your own infrastructure. That means that they go with AWS or Rackspace or something.
So my question is, who do you expect to be implementing OpenStack other than cloud providers (e.g. Rackspace) and a relatively small number of companies looking to build their own cloud infrastructure?
As an IT guy (not a developer), the whole thing is still pretty unclear. What would I use OpenStack for? If I wanted to test it out, what would I need to get started? How would I set it up? What, then could I do with it? Most of the appeal of "the cloud" at this point is the potential to divest myself of responsibility for its maintenance. The only people that I can imagine making use of OpenStack are large companies with large public, business critical web applications, and even then only those who, for whatever reason, don't want to use AWS or Rackspace or some other vendor, and have the resources to build and maintain a bunch of cloud infrastructure. Yes, there are businesses that fit that description, but it's not a large percentage of businesses.
And I'm not sure I'd call them "end users".
When he says that robots aren't "competent", I don't think that he's saying that they can't do things. He's just pointing out they they only do certain specific things that they've been told to do, even if they do those things extremely well.
I think the example used points this out: The question is asked, "If the robotic car be put in the position of killing 1 person in order to save 2 people, how should it make the decision?" He's saying that there's a problem with the question, which is the assumption that the robot will be capable of understanding such a scenario.
With our current engineering techniques, we can't expect the robot to understand what it's doing, nor the moral implications. We can't program it to actually understand whether it will kill people. The most we can program it to do is, given a detection of some heuristic value, follow a certain protocol of instructions. So for example, if the robotic car can detect that it's about to hit someone, try to stop. If it calculates that it will be unable to stop, try to swerve. You might program it to detect people specifically and place extra priority on swerving around them, e.g. "if you're about to hit something identified as a person, or hit a road sign, choose to hit the road sign". We might even get it to do something like, "If you're losing control and you can detect several people, and you can't avoid the whole crowd, swerve into the sparsest area of the crowd while slowing as much as possible.
The engineers should try to anticipate these kinds of things. We as citizens should also debate about how we'd want these kinds of instructions should work to avoid legal liability. For example, we might say that in order for the AI to be legal, it must show that it will stop the car when [event x] happens. But to ask, "how will the car make moral decisions?" fundamentally misunderstands its decision-making capabilities. The answer is, "It won't make moral decisions at all."
You're conflating a lot of different issues. First, video calls are notoriously painful for various reasons. So let's just get that out of the way: it wouldn't be weird if you were having lots of problems with Skype, too.
Second, there's nothing inherently inferior about "open". If Skype were to publish a spec for how they negotiate video calls, then suddenly we have an open protocol that's as good as Skype. It's not suddenly worse because it's "open".
Third, there's a difference between a "protocol" and a "platform". It seems you're talking about having tried different pieces of free software, and had problems with them. The problems might have had nothing to do with the protocol. It might be that the software is bad. I don't know, because I don't know what problems you've had on which platforms.
We use "open standards" all the time. It's silly to suggest that open protocols don't work. How are you posting on this website? I'm guessing you're making some use of HTTP.
So law enforcement budgets will be lower, but the need for law enforcement will also be lower because you won't have to pay as many cops to run around patrolling the roads and writing tickets. Plus there will be fewer injuries and less property damage due to reckless driving, which means less economic waste.
If law enforcement legitimately needs more money, then raise taxes and pay for it. People keep talking like it's bad for the economy to permanently address problems because we'll have fewer jobs consisting of temporarily patching those problems. It's just another variation on the "broken window fallacy".
I actually think there's a bit of a cultural problem in the tech community, in that the issue of "openness" has become polarized. On one side, you have people who think openness absolutely doesn't matter, and they seem to have no problem with the "walled gardens". On the other side, you have FOSS advocates who seem to have a militant agenda to replace everything with Debian.
I would take the position that closed source software is fine, and in fact, it's good to have a diverse software ecosystem with different developers taking different approaches, open and closed source both. However, I think we should push a militant agenda for open formats and open protocols.
For example, if Google wants to have their own closed-source Hangouts app, and Facebook wants their Messenger app, and Pidgin wants to produce an open source messaging app, that's all fine. That's great, in fact. However, we should try to get them to round everyone up and agree on messaging protocols that allow users of one IM platform to communicate with users of another platform.
The equivalent for email would be if we all lived in a world where Gmail users could only email other Gmail users, and Hotmail users could only email other Hotmail users. I'm just saying, let's go ahead and develop something like SMTP so that they can talk to each other.
They never really explained why federation wouldn't work or why XMPP wasn't sufficient for their needs.
I'm not asserting that was why they did it. I'm just saying that I could understand if that was why.
It may be that if you could talk to the decision-maker inside of Google who made this decision, they'd tell you that XMPP is somehow inefficient, or it didn't offer features that they wanted. They might say that XMPP is poorly architected or something, and we might debate about whether their explanation made sense.
What I'm saying is that, if there's some technical explanation like that, then I don't object to the decision per se. However, then I would want to argue that Google should either fix it or offer a better alternative. IM, voice, and even video chats are such well understood problems at this point, that I don't believe there's a valid reason why there can't be open protocols that are shared among Hangouts, Facebook, Skype, AOL, and iMessage.
I'm not talking about taking away your choice to be in a walled garden. I haven't suggested any method to stop you from logging onto Facebook and only using Facebook.
But going with that example, I'm just suggesting that, as more and more of our communications get rammed into Facebook, and if Facebook doesn't have protocols to connect without outside systems, we're going to have a problem.
You know, I can understand why Google might decide that XMPP isn't sufficient for the kinds of features they'd like to support, and so deciding to develop something new in-house with their desired feature set. I really wish, though, they they would open a protocol that still allowed outside people to communicate.
I just find it insane how much we're moving back in the direction of "walled gardens" everywhere. There was a time when most people's exposure to online interaction were services like Compuserve, AOL, and Prodigy, and those services couldn't talk to each other. I think we're headed back in that direction, except that soon we'll all be on services like Google+, Facebook, and Twitter, and those services won't talk to each other.
We really need a revolution soon, or I think we're going to find that we don't like where we end up. I know it sounds trivial because these are all free services, and most of what's communicated on them is trivial anyway. Still, it's transforming the Internet into a less free place, where we're all at the whim of a small handful of companies. I think it's a bigger problem than we've yet realized.
This is a really good point. Current CPUs have billions of cycles per second, but still struggle to perform some tasks in real-time, and that processing is not going to be powerful enough to emulated intelligence to the degree of consciousness. If past computing problems are any indication, I would guess that the first generation of AI will be a bit "slow on the uptake". That is to say, we may come up with the algorithms to emulate consciousness first, and then need to spend some time optimizing code and improving hardware designs in order to get "real time" consciousness.
I think it's important to keep in mind that there's a point at which "more security" stops making sense and "more insurance" becomes a better option. I've had clients get overly-obsessed with security, trying to buy software that can locate/control your lost/stolen items remotely, locking everything down for physical security, etc. Then when they look at the project to secure everything, I point out that it'd be easier to insure everything instead. Along with everything else, there's no perfect security. You could go through all the effort and expense of securing things, and it could still get stolen.
Aside from that, consider whether you can just reinforce security around a closet and lock everything in there. And then train people to arm the house alarm before leaving. Even the most secure door isn't going to keep your house secure if people keep propping it open.
I don't find your explanation very clear. I understand that if, in this scenario, someone else gets 301-555-1234 and associates that number with their own iMessage account, that the messages will then be routed to their account. Also, if I set up my iMessage account to be associated with a new number, I believe it drops the old one. But what if they don't sign up for iMessage, and I don't get a new cell phone?
Because it seems to be that for each iMessage account, Apple stores a phone number for the cell phone, and then a set of email addresses. You can then address messages to either the phone number or the email address, and it gets delivered to the recipient. So if Apple isn't notified in any way that the phone number has been changed, wouldn't they keep routing messages to the old account? And then, wouldn't I still be able to receive those messages on my computer or iPad, even though I didn't have that phone number anymore?
I believe that's what happens if the sending phone can't send through iMessage, but it doesn't necessarily address what happens if the receiving phone doesn't receive the message.
Essentially you can set your iPhone to register your phone number to an iMessage account, which you can think of like an email account. So once you've registered your number, when an iPhone has a data connection, it will send the text message to this "email account" rather than sending it via SMS, even if the receiving iPhone is offline. If the sending iPhone doesn't have a data connection, it will failover to using SMS, but when it sends the message, it can't determine whether the receiving iPhone has a data connection. So even if you turn your phone off, it will send the message to this "email account" in lieu of SMS, and those messages can then be accessed on a Mac or iOS device.
So I imagine that the problem boils down to this: When you switch to using an iPhone and set up iMessage, you're notifying Apple that they can route your text messages through their "email server" instead of SMS, so they start doing that. When you switch away from using an iPhone, there isn't necessarily anything to notify Apple to stop routing text messages to the "email server", so they keep doing it. You could manually deauthorize iMessage from your phone number, but people might not remember to do that.
What seems potentially more troubling-- and I don't know if it's happened-- is the prospect that this could happen with an abandoned phone number. So imagine I have an iPhone and my phone number is 301-555-1234. I register that phone number to iMessage, so Apple begins routing text messages from iPhone users to iMessage. I then decide that I don't want a cell phone anymore, so I cancel my service and abandon the phone number. Then someone else gets a new cell phone and they are assigned the phone number 301-555-1234, but their phone is not an iPhone. Is there anything to tell Apple to stop routing that person's text messages to my iMessage account?
Yes, there are concerns about reliability on a day-to-day level, as well as the question of "Will this service be around in 3 years?" And related: "How much money are we going to spend transitioning to a service that might not be around in 3 years, and then how much money will we spend transitioning off if it goes away or we don't like it?"
But there are more problems than that: in some contexts, the "Cloud" services just aren't as good. If my "network" is made up of a bunch of laptops traveling throughout the country, then a "cloud" file sharing service like Dropbox might be very handy. If, however, my network is a LAN with a bunch of workstations hard-lined into it, and I have 5 TB of files stored on a file server, then moving that file server to Dropbox might not offer any improvement at all. If I'm managing those workstations with a Windows domain to provide group policies and single sign-on, there isn't a cloud service that I'm aware of that provides the same functionality as simply and elegantly. You also have to consider which model serves users better when the Internet is down or slow. If everything is on the Internet, then when the Internet goes out, your business is shut down.
So I don't know who Curtis Peterson is, when people start talking derisively about the use of local servers, I usually guess that they've never done real IT work. There are still a lot of situations where you need too much control, too much security, and too much bandwidth to push it all offsite-- regardless of whether you call it "the cloud" or "a hosted server" or "a collocated server". As an IT guy, I'd love to move everything to "the cloud", but it's not ready. And it won't be ready until we (a) have ubiquitous, high speed, highly reliable Internet everywhere; and (b) the "cloud" becomes more built on open formats, APIs and protocols rather than having a bunch of big businesses pushing us into little walled gardens.
Not just that, but they're putting the start menu back in Windows. I'm starting to like this new CEO.
I'd imagine that nobody has come up with an assassination robot because of the need for stealth. It'd be hard enough to have a robot target a specific individual, but to do it without alerting anyone ahead of time would be much trickier. I would think that poison or a bomb would be easier.
Now if you're talking about a cruise missile, then I'm not sure what's gained by having it be completely autonomous. You may as well have someone sitting in a bunker someplace selecting the target and deciding whether to fire it, and then having appropriate computerized guidance.
Yeah, I always find it funny when people cite the "3 laws" as though they were brilliant fail-safe mechanisms that we should of course put into robots in reality. Did nobody actually read Asimov's stories? They're a catalog of examples of how the 3 laws would fail, or at least of how they'd be too ambiguous.
Beyond that, I see another problem with the idea of banning development of autonomous weapons: most of the technology involved would probably be developed anyway because it would be widely applicable.
Think about it. If you were going to make a killer robotic soldier, what technology would be hard to develop? It's difficult to make a robot that can easily traverse diverse terrain, but we'll work on that for other reasons. Making an AI that can accurately identify people by facial features, clothing, and speech patterns would be hard. We'd also do that for other reasons. There are a million reasons to develop and intelligent free-roaming robot who can identify people and interact with them.
Once you have a robot that can do those kinds of things, turning the "interaction" into "fire a weapon at that person" is easy. It's not hard for a computer to aim once it has its target. It's not hard for a computer to trigger the weapon itself.
And there are still record stores out there, and people who go to them.
Good point. I suspect that when people hear the term "cyber-terrorism", somewhere in their subconscious or unconscious, they imagine terminator-like cyborgs with bombs strapped to their chests. Or something like that.