There's overlap between containers and running a different user, but unlike running under a different user, a container:
1. Can't see what applications are installed on the machine in the global/bin and other path locations
2. Can have the amount of RAM, disk space, and CPU they can use capped.
3. Can't see much other aspects of the host - like a list of active sockets, how much memory is used, etc...
If you just want to run your own applications in an isolated fashion as an extra layer of security, I think using separate user accounts is probably good enough. But I'm not a professional in security, I'm just a dangerous novice.
But unless you're doing something that's waiting for disk input and output or network input and output, the difference isn't 4%. The micro-benchmarks at the Great Computer Language Shootout page are a simple starting point. For Java vs. C++, for some reason the chart (section 2) doesn't show memory difference correctly. The measurements section (section 3) does - Java is about 2x slower than C++ in most of the benchmarks, but only comes within 2x of C++ for memory usage in a few places, in most other micro benchmarks the memory difference is higher, even 20 times higher. ( http://benchmarksgame.alioth.d... )
I'm guessing what you really mean with the question is, "Does this bring anything to the table that I might care about that Groovy doesn't?"
Both languages have dynamic typing. Both have a REPL. Depending upon what task you're trying to accomplish, both will let you get it done with far less syntactic overhead than Java without sacrificing readability (i.e. no crazy implicit variables or bizarre syntax shortcuts). Groovy has optional static types, while Scheme does not out of the box. On the other hand, as a member of the Lisp family Scheme has pretty easy syntax to understand, and more feature-rich macros than any non-Lisp language.
Me, I'm transitioning into a Lisp weenie as I get older, though I'm not competent enough with any dialect of Lisp to start growing my neckbeard. I like Groovy and Scheme, so I don't think you can go wrong either way. As a plus, Groovy might be an easier sell to people comfortable with Java. Getting people accustomed to C-language family syntax to try Lisp family syntax can be difficult.
The problem is, most of us are crappy programmers for a few years, or even more than a decade, before we're decent software developers. So our pain is inevitable - if you stop the underqualified novices from doing work, you've saved yourself some pain but you've reduced the number of developers of the future.
The ideal solution, as far as I can tell, is more mentorship and closer supervision of novices. You let the same learners write the same garbage code, but then someone who knows what they're doing and is specifically assigned to spend half of their time watching the novices will review and reject most of their work - while providing an explanation as to why it was rejected and what should be done differently.
But in reality, most companies are in such a rush to get the next release to market that they let the novices work unsupervised and put the senior developers at work in other areas. Then two months or six months or three years later the novices have moved on, and the senior developers are too busy dealing with technical debt from the previous novices to work on new features or shepherd the latest round of novices.
But if I had been blocked from writing code when my code was crap - and my code was crap for a long time - I'd never have reached the point where I'm at today. I'm no genius, I'm no industry leader, but I can recognize most of the errors I made five and ten years ago.
Thanks for the information. It's odd - and sad, I guess - that I heard of Clojure before I heard of Kawa (or Armed Bear Common Lisp, which as you probably already known is a Common Lisp implementation that runs on the JVM).
I have golden handcuffs at my current job, I work with some of the nicest, most professional, and especially most intelligent colleagues and managers I've had the privilege to encounter. So I'm not looking to leave soon for any reason. But most of my work is in vanilla Java, and I'm sick of it.
I don't care, really - if Clojure gets more adoption or Kawa gets more adoption or both get more adoption, it's a win. Anything to make the world move towards the Lisp family is a win.
But that's the whole point. My employer does everything on the JVM for our production websites and testing. I can't get them to introduce PHP, Basic, Pascal, Ada, Perl, Haskell, OCaml, or Fortran for anything. I also can't get them to seriously consider CPython, native Ruby, SBCL (Lisp), or DrScheme.
But if I want to introduce JRuby, Jython, Scala, Groovy, Clojure, or Javascript (available in the JVM via Rhino in older versions of Java and via Nashorn in Java 7), I can get consideration.
So I suspect Kawa is an attempt to build a Scheme developers can use at work, for production, without convincing the CTO to scrap the existing JVM-based technology stack and starting over from square one. I wish them good luck. I haven't looked at Kawa yet, I'm still hoping to get my boss to look at Clojure.:)
I have a 2010 Ford with the non-touch screen Sync, because I didn't want the touch screen. Most of the time Sync works fine - once in a while it becomes unresponsive for a few minutes.
You're missing all of the other aspects and focusing on static linking. Okay, that's not fair - you're also correct that puppet or chef should be used instead of just copying image files around. A container also gets you:
1. Isolating contained software from the rest of the operating system, so you can host third party applications without worrying about them inspecting their host environment.
2. Limited contained software's ability to use host resources - disk space, CPU, memory, network IO, disk IO. You can do all of those same things using Linux kernel cgroups, but that's the whole point of containers - they are built on cgroups.
3. Reduce the amount of coordination required between your developers and your sysadmins.
You're right that developers create dependency hell left and right. But a software development shop exists to ship product that's good enough for the customers to use. You have to weigh library standardization - or standardization on anything - with the benefits and drawbacks it brings against the costs in developer speed. Developers tend to over value the newest thing, and that's a path to headaches. But if you lock yourself into a specific version of something, at some point the productivity you're missing will start costing you more than you gain with your simpler infrastructure.
Docker et al are mostly wrappers for cgroups and selinux. The static linking tradeoff is not the big deal. The big deal is that you get most of the benefits of whole operating system virtualization with lower overhead. You can set strict limits on the amount of disk space, disk IO, network bandwidth, memory, and CPU resources the container can use, and block the container from knowing anything about the host operating system, and block the container from knowing about any other containers on the machine. And you can copy the container and all of its specific restrictions to other servers in a relatively straightforward way. You can do all of those same things for a virtual machine, but your virtual machine also contains a virtual kernel and the extra disk space required for an operating system.
Ideally, you have two layers:
0. Host operating system to run the bare hardware.
1. Containers to isolate running contained applications from each other, and govern their resource access.
The application runs inside the container, without any virtual anything.
With Java, in theory you could run Java on the host operating system under different user accounts. So you have the host operating system at level 0 and the JVMs running at level 1, and you use different user accounts to set different JAVA_HOMEs and give different JRE versions and Java's own security configuration features to restrict resource use (in addition to Java's own application security configurations, there's the jcgroup library https://github.com/haosdent/jc... to restrict CPU utilization, etc...)
But in practice, the JVM has had some many security vulnerability disclosures over the past few years that I wouldn't trust it. If I were to use the JVM, I would go for a three tier application: 0. host, 1. containers, 2. JVM inside containers.
I wrote this elsewhere, but to repeat: the advantage of Docker and similar containers isn't static linking. The advantage is that you get most of the important benefits of whole operating system virtualization with much lower overhead in terms of disk space and resource use. Instead of building one 5GB CentOS or Ubuntu VM that runs a copy of your web server software and pushing that all over your network and having every running instance hold 100MB of RAM just for a virtual kernel in addition to the web server itself, you build a 500MB Apache/Nginx/Whatever Docker container with the same web server and push it everywhere, and its memory and CPU overhead on top of the web server is tiny. And since, yes, it uses statically linked libraries, it doesn't matter if the host OS has a different version of libevent as long as it has a compatible version of Docker or lmctfy or whatever container technology you use.
Now obviously if you wanted to make the virtualized environment available to a remote user as a remote desktop, or for remote login directly into the virtual environment with ssh for configuration changes, you want a full virtualized operating system. In that case you need VirtualBox, KVM, Xen, VMware, Hyper-V, etc... but for deploying identical instances of a configured application to a handful or even hundreds of machines with the smallest feasible overhead and a nice security layer to prevent most breaches of the hosted application from leaking into the host operating system, a container is great. If you look up how Docker and lmctfy work, they are mostly an API wrapper around the Linux kernel cgroup and selinux features for configurable restriction of a process's ability to utilize CPU, RAM, and IO.
The reason to use containers is isolation - the thing inside the container has a rigidly defined and strictly controlled limit to what external resources it can access and how much computing resources it can see and use: how many CPU cores and how much of each core it can utilize, disk space and rate of disk input and output, network resources and rate of network input and output, RAM, etc...
So yes, you lose the advantage of statically linked libraries. But it gives you most of the important advantages of operating system virtualization with less overhead since there's no virtual kernel to handle. For a big chunk of the people using VMware, Virtualbox, KVM (Kernel Virtual Machine, not Keyboard-Video-Mouse), etc... in production, these containers are what they really wanted but didn't have available in a mature form six or ten years ago.
I don't see how there are any GPL/LGPL issues. Compiling the code for compiled languages is separate from sticking it into a container, so I don't see how Docker, or anything like Docker, would let a company escape the need for GPL and LGPL license compliance.
Good point, but it's possible that - if you'll forgive me for stereotyping - she wants him to get rid of the gaming PC so that they can go pick out drapes and matching color bedding. In that case, I'd prefer to game too.
Both are bad, and arguably sitting around debating which is worse is a waste of time when both are a problem. But historically, for most of human history women were treated as second class citizens or slaves. If the pendulum of balance of power in a typical heterosexual relationship swings a little too far towards the women for a few generations before it finds a nice fair mid-point, that doesn't bother me as much as the thought of having the pendulum stay where it has been since we were bashing each other with sticks and living in caves.
A lot of the people posting obnoxious comments here are treating marriage as though the woman gets what she wants and the guy has to put up with it. Some other people are posting that the woman should be dominated and put into her place as some kind of inferior that should be bossed around by her husband. Your "expect women to be women, and wives" comment sounds like you're part of the second group, and that's even more obnoxious than the second group.
A relationship is about compromise on both sides. If the wife of the original writer tells him that he can have any gaming PC he wants, she just doesn't want to hear PC fans in the living room, then he can set up his gaming den somewhere else and spend most of his leisure time there instead of the living room. He gets his PC, he gets his gaming time, he gets a place to game, she gets her quiet living room, she doesn't get her husband to give up gaming. Everyone compromised, everyone gets something they want. If, on the other hand, this is just a precursor to her trying to get him to give up gaming completely then it's a domineering relationship and he shouldn't be married to her (and until she changes her attitude, nobody should be married to her).
You should both bring some of everything. My wife and I split the housework, she's a better cook, so she cooks and I wash the dishes. We both do some of the laundry. We work through the bills together. I take the dog out in the morning and afternoon, she takes it out in the evenings and late at night (that's more work, but she wanted a pet a lot more than I did). Whichever of us happens to be home at the time checks the kids' homework. At this particular point in time I contribute more to the household income than she does, but she earned more money than me for the first eight years of marriage.
Keeping your testicles cold relative to the rest of your body increases your sperm count. So if anything, guys in kilts are more manly than the rest of us.
He didn't necessarily marry the wrong girl. What he did do is fail to communicate with her before they got married. If your partner is not a gamer and you are, and you want a gaming PC to be in the living room for the rest of your life, you have to discuss that with your partner long before you get enter a permanent commitment. Likewise with every other aspect of the relationship - how many kids you plan to have (0 is a valid answer), what percentage of your combined income should go into retirement accounts and savings, what kind of vehicles you will purchase, what sex acts you expect and which ones you are (and more importantly, are not) willing to forego (real life is not porn, not every guy or girl is into oral sex, anal sex, or getting sprayed with... whatever), how often you'll make obligatory visits to the in-laws, what you'll do if one of your parents gets too sick to live alone, how you'll handle any differences between your religions, how you will divide the housework and yard work, etc... etc...
As a blunt but practical point, every adult woman has anatomy a guy can enjoy. The important parts are really communication, work ethic, and intelligence.
People would switch if the open source, decentralized social networking technology was also easy to use, had a good user interface, and offered all of the features of the commercial centralized social networks except for advertising.
Getting al of that to work is difficult, but it's a worthwhile problem to solve.
Look at the problems you're trying to solve if you want a viable Facebook or Twitter alternative that's distributed and private.
1. Any user has got to be able to get involved, the barrier to entry in terms of technical knowledge should be as low as possible.
2. All data should be stored encrypted and moved around encrypted, so a person has to hack your personal machine (laptop, desktop, phone) to decrypt anything you have hosted on the network or that has been shared with you by a friend.
3. Because there is no central hosting, the network should have some kind of builtin distributed backup system.
For a while it looked like a fundamentally unsolvable problem to me, but some groups have at least an idea of an answer and are working on it. There's crypto-currency (off hand I think "maidsafe", "quark", and "ethereum", but I could be remembering wrong) that is under development that lets users farm coins based on the resources they make available to the crypto-currency network: RAM, CPU, and storage. If you contribute more of those resources to the network than you consume, you accumulate extra currency you can use to buy real things. If you contribute less, you have to buy currency to cover your operating costs. All that seems tangential to a distributed social network, but you can link the two. Host the distributed social network on the computing resources made available by that crypto-currency. Your messages and data transfers to other users are tiny micro-transactions on the crypto-currency market. Your backups are micro-transactions on the crypto-currency market, and all of the redundant backups are encrypted. The same public/private key infrastructure governing transactions can be hooked into to make sure all data is encrypted in transit. Anyone that wants to participate can install the client on a phone, laptop, or desktop and get started.
Who knows if it will ever actually work. But as crazy as it is, it seems to have a more realistic chances of mainstream success than something like Diaspora. With Diaspora you need to trust your hosting provider or else have the technical knowhow and interest to host your own, and that absolutely won't scale large enough to make a dent in the established players.
Agreed. Even though Google had a few hiccups in which the Google plus interface was annoying, overall I like the site much more than Facebook. But I have nearly fifty fairly active friends and family members on Facebook. All of the friendships I made on Google plus are with people that share a common interest. And I like that, but it doesn't let me share photos of the kids with my extended family or discuss a holiday party with friends.
Slashdot Mirror
There's overlap between containers and running a different user, but unlike running under a different user, a container: /bin and other path locations
1. Can't see what applications are installed on the machine in the global
2. Can have the amount of RAM, disk space, and CPU they can use capped.
3. Can't see much other aspects of the host - like a list of active sockets, how much memory is used, etc...
If you just want to run your own applications in an isolated fashion as an extra layer of security, I think using separate user accounts is probably good enough. But I'm not a professional in security, I'm just a dangerous novice.
But unless you're doing something that's waiting for disk input and output or network input and output, the difference isn't 4%. The micro-benchmarks at the Great Computer Language Shootout page are a simple starting point. For Java vs. C++, for some reason the chart (section 2) doesn't show memory difference correctly. The measurements section (section 3) does - Java is about 2x slower than C++ in most of the benchmarks, but only comes within 2x of C++ for memory usage in a few places, in most other micro benchmarks the memory difference is higher, even 20 times higher. ( http://benchmarksgame.alioth.d... )
I'm guessing what you really mean with the question is, "Does this bring anything to the table that I might care about that Groovy doesn't?"
Both languages have dynamic typing. Both have a REPL. Depending upon what task you're trying to accomplish, both will let you get it done with far less syntactic overhead than Java without sacrificing readability (i.e. no crazy implicit variables or bizarre syntax shortcuts). Groovy has optional static types, while Scheme does not out of the box. On the other hand, as a member of the Lisp family Scheme has pretty easy syntax to understand, and more feature-rich macros than any non-Lisp language.
Me, I'm transitioning into a Lisp weenie as I get older, though I'm not competent enough with any dialect of Lisp to start growing my neckbeard. I like Groovy and Scheme, so I don't think you can go wrong either way. As a plus, Groovy might be an easier sell to people comfortable with Java. Getting people accustomed to C-language family syntax to try Lisp family syntax can be difficult.
The problem is, most of us are crappy programmers for a few years, or even more than a decade, before we're decent software developers. So our pain is inevitable - if you stop the underqualified novices from doing work, you've saved yourself some pain but you've reduced the number of developers of the future.
The ideal solution, as far as I can tell, is more mentorship and closer supervision of novices. You let the same learners write the same garbage code, but then someone who knows what they're doing and is specifically assigned to spend half of their time watching the novices will review and reject most of their work - while providing an explanation as to why it was rejected and what should be done differently.
But in reality, most companies are in such a rush to get the next release to market that they let the novices work unsupervised and put the senior developers at work in other areas. Then two months or six months or three years later the novices have moved on, and the senior developers are too busy dealing with technical debt from the previous novices to work on new features or shepherd the latest round of novices.
But if I had been blocked from writing code when my code was crap - and my code was crap for a long time - I'd never have reached the point where I'm at today. I'm no genius, I'm no industry leader, but I can recognize most of the errors I made five and ten years ago.
Thanks for the information. It's odd - and sad, I guess - that I heard of Clojure before I heard of Kawa (or Armed Bear Common Lisp, which as you probably already known is a Common Lisp implementation that runs on the JVM).
I have golden handcuffs at my current job, I work with some of the nicest, most professional, and especially most intelligent colleagues and managers I've had the privilege to encounter. So I'm not looking to leave soon for any reason. But most of my work is in vanilla Java, and I'm sick of it.
I don't care, really - if Clojure gets more adoption or Kawa gets more adoption or both get more adoption, it's a win. Anything to make the world move towards the Lisp family is a win.
But that's the whole point. My employer does everything on the JVM for our production websites and testing. I can't get them to introduce PHP, Basic, Pascal, Ada, Perl, Haskell, OCaml, or Fortran for anything. I also can't get them to seriously consider CPython, native Ruby, SBCL (Lisp), or DrScheme.
:)
But if I want to introduce JRuby, Jython, Scala, Groovy, Clojure, or Javascript (available in the JVM via Rhino in older versions of Java and via Nashorn in Java 7), I can get consideration.
So I suspect Kawa is an attempt to build a Scheme developers can use at work, for production, without convincing the CTO to scrap the existing JVM-based technology stack and starting over from square one. I wish them good luck. I haven't looked at Kawa yet, I'm still hoping to get my boss to look at Clojure.
I have a 2010 Ford with the non-touch screen Sync, because I didn't want the touch screen. Most of the time Sync works fine - once in a while it becomes unresponsive for a few minutes.
You're missing all of the other aspects and focusing on static linking. Okay, that's not fair - you're also correct that puppet or chef should be used instead of just copying image files around. A container also gets you:
1. Isolating contained software from the rest of the operating system, so you can host third party applications without worrying about them inspecting their host environment.
2. Limited contained software's ability to use host resources - disk space, CPU, memory, network IO, disk IO. You can do all of those same things using Linux kernel cgroups, but that's the whole point of containers - they are built on cgroups.
3. Reduce the amount of coordination required between your developers and your sysadmins.
You're right that developers create dependency hell left and right. But a software development shop exists to ship product that's good enough for the customers to use. You have to weigh library standardization - or standardization on anything - with the benefits and drawbacks it brings against the costs in developer speed. Developers tend to over value the newest thing, and that's a path to headaches. But if you lock yourself into a specific version of something, at some point the productivity you're missing will start costing you more than you gain with your simpler infrastructure.
PaaS too, right?
Docker et al are mostly wrappers for cgroups and selinux. The static linking tradeoff is not the big deal. The big deal is that you get most of the benefits of whole operating system virtualization with lower overhead. You can set strict limits on the amount of disk space, disk IO, network bandwidth, memory, and CPU resources the container can use, and block the container from knowing anything about the host operating system, and block the container from knowing about any other containers on the machine. And you can copy the container and all of its specific restrictions to other servers in a relatively straightforward way. You can do all of those same things for a virtual machine, but your virtual machine also contains a virtual kernel and the extra disk space required for an operating system.
Ideally, you have two layers:
0. Host operating system to run the bare hardware.
1. Containers to isolate running contained applications from each other, and govern their resource access.
The application runs inside the container, without any virtual anything.
With Java, in theory you could run Java on the host operating system under different user accounts. So you have the host operating system at level 0 and the JVMs running at level 1, and you use different user accounts to set different JAVA_HOMEs and give different JRE versions and Java's own security configuration features to restrict resource use (in addition to Java's own application security configurations, there's the jcgroup library https://github.com/haosdent/jc... to restrict CPU utilization, etc...)
But in practice, the JVM has had some many security vulnerability disclosures over the past few years that I wouldn't trust it. If I were to use the JVM, I would go for a three tier application: 0. host, 1. containers, 2. JVM inside containers.
I wrote this elsewhere, but to repeat: the advantage of Docker and similar containers isn't static linking. The advantage is that you get most of the important benefits of whole operating system virtualization with much lower overhead in terms of disk space and resource use. Instead of building one 5GB CentOS or Ubuntu VM that runs a copy of your web server software and pushing that all over your network and having every running instance hold 100MB of RAM just for a virtual kernel in addition to the web server itself, you build a 500MB Apache/Nginx/Whatever Docker container with the same web server and push it everywhere, and its memory and CPU overhead on top of the web server is tiny. And since, yes, it uses statically linked libraries, it doesn't matter if the host OS has a different version of libevent as long as it has a compatible version of Docker or lmctfy or whatever container technology you use.
Now obviously if you wanted to make the virtualized environment available to a remote user as a remote desktop, or for remote login directly into the virtual environment with ssh for configuration changes, you want a full virtualized operating system. In that case you need VirtualBox, KVM, Xen, VMware, Hyper-V, etc... but for deploying identical instances of a configured application to a handful or even hundreds of machines with the smallest feasible overhead and a nice security layer to prevent most breaches of the hosted application from leaking into the host operating system, a container is great. If you look up how Docker and lmctfy work, they are mostly an API wrapper around the Linux kernel cgroup and selinux features for configurable restriction of a process's ability to utilize CPU, RAM, and IO.
The reason to use containers is isolation - the thing inside the container has a rigidly defined and strictly controlled limit to what external resources it can access and how much computing resources it can see and use: how many CPU cores and how much of each core it can utilize, disk space and rate of disk input and output, network resources and rate of network input and output, RAM, etc...
So yes, you lose the advantage of statically linked libraries. But it gives you most of the important advantages of operating system virtualization with less overhead since there's no virtual kernel to handle. For a big chunk of the people using VMware, Virtualbox, KVM (Kernel Virtual Machine, not Keyboard-Video-Mouse), etc... in production, these containers are what they really wanted but didn't have available in a mature form six or ten years ago.
I don't see how there are any GPL/LGPL issues. Compiling the code for compiled languages is separate from sticking it into a container, so I don't see how Docker, or anything like Docker, would let a company escape the need for GPL and LGPL license compliance.
Good point, but it's possible that - if you'll forgive me for stereotyping - she wants him to get rid of the gaming PC so that they can go pick out drapes and matching color bedding. In that case, I'd prefer to game too.
Cool. Thanks for the information. I tried it with Minecraft and it failed badly.
Both are bad, and arguably sitting around debating which is worse is a waste of time when both are a problem. But historically, for most of human history women were treated as second class citizens or slaves. If the pendulum of balance of power in a typical heterosexual relationship swings a little too far towards the women for a few generations before it finds a nice fair mid-point, that doesn't bother me as much as the thought of having the pendulum stay where it has been since we were bashing each other with sticks and living in caves.
A lot of the people posting obnoxious comments here are treating marriage as though the woman gets what she wants and the guy has to put up with it. Some other people are posting that the woman should be dominated and put into her place as some kind of inferior that should be bossed around by her husband. Your "expect women to be women, and wives" comment sounds like you're part of the second group, and that's even more obnoxious than the second group.
A relationship is about compromise on both sides. If the wife of the original writer tells him that he can have any gaming PC he wants, she just doesn't want to hear PC fans in the living room, then he can set up his gaming den somewhere else and spend most of his leisure time there instead of the living room. He gets his PC, he gets his gaming time, he gets a place to game, she gets her quiet living room, she doesn't get her husband to give up gaming. Everyone compromised, everyone gets something they want. If, on the other hand, this is just a precursor to her trying to get him to give up gaming completely then it's a domineering relationship and he shouldn't be married to her (and until she changes her attitude, nobody should be married to her).
You should both bring some of everything. My wife and I split the housework, she's a better cook, so she cooks and I wash the dishes. We both do some of the laundry. We work through the bills together. I take the dog out in the morning and afternoon, she takes it out in the evenings and late at night (that's more work, but she wanted a pet a lot more than I did). Whichever of us happens to be home at the time checks the kids' homework. At this particular point in time I contribute more to the household income than she does, but she earned more money than me for the first eight years of marriage.
Nice :) - and accurate.
Keeping your testicles cold relative to the rest of your body increases your sperm count. So if anything, guys in kilts are more manly than the rest of us.
He didn't necessarily marry the wrong girl. What he did do is fail to communicate with her before they got married. If your partner is not a gamer and you are, and you want a gaming PC to be in the living room for the rest of your life, you have to discuss that with your partner long before you get enter a permanent commitment. Likewise with every other aspect of the relationship - how many kids you plan to have (0 is a valid answer), what percentage of your combined income should go into retirement accounts and savings, what kind of vehicles you will purchase, what sex acts you expect and which ones you are (and more importantly, are not) willing to forego (real life is not porn, not every guy or girl is into oral sex, anal sex, or getting sprayed with... whatever), how often you'll make obligatory visits to the in-laws, what you'll do if one of your parents gets too sick to live alone, how you'll handle any differences between your religions, how you will divide the housework and yard work, etc... etc...
As a blunt but practical point, every adult woman has anatomy a guy can enjoy. The important parts are really communication, work ethic, and intelligence.
You can't game anything remotely graphics-intensive across RDP. I know, I've tried it.
People would switch if the open source, decentralized social networking technology was also easy to use, had a good user interface, and offered all of the features of the commercial centralized social networks except for advertising.
Getting al of that to work is difficult, but it's a worthwhile problem to solve.
Look at the problems you're trying to solve if you want a viable Facebook or Twitter alternative that's distributed and private.
1. Any user has got to be able to get involved, the barrier to entry in terms of technical knowledge should be as low as possible.
2. All data should be stored encrypted and moved around encrypted, so a person has to hack your personal machine (laptop, desktop, phone) to decrypt anything you have hosted on the network or that has been shared with you by a friend.
3. Because there is no central hosting, the network should have some kind of builtin distributed backup system.
For a while it looked like a fundamentally unsolvable problem to me, but some groups have at least an idea of an answer and are working on it. There's crypto-currency (off hand I think "maidsafe", "quark", and "ethereum", but I could be remembering wrong) that is under development that lets users farm coins based on the resources they make available to the crypto-currency network: RAM, CPU, and storage. If you contribute more of those resources to the network than you consume, you accumulate extra currency you can use to buy real things. If you contribute less, you have to buy currency to cover your operating costs. All that seems tangential to a distributed social network, but you can link the two. Host the distributed social network on the computing resources made available by that crypto-currency. Your messages and data transfers to other users are tiny micro-transactions on the crypto-currency market. Your backups are micro-transactions on the crypto-currency market, and all of the redundant backups are encrypted. The same public/private key infrastructure governing transactions can be hooked into to make sure all data is encrypted in transit. Anyone that wants to participate can install the client on a phone, laptop, or desktop and get started.
Who knows if it will ever actually work. But as crazy as it is, it seems to have a more realistic chances of mainstream success than something like Diaspora. With Diaspora you need to trust your hosting provider or else have the technical knowhow and interest to host your own, and that absolutely won't scale large enough to make a dent in the established players.
Agreed. Even though Google had a few hiccups in which the Google plus interface was annoying, overall I like the site much more than Facebook. But I have nearly fifty fairly active friends and family members on Facebook. All of the friendships I made on Google plus are with people that share a common interest. And I like that, but it doesn't let me share photos of the kids with my extended family or discuss a holiday party with friends.