95% uptime isn't that much, really. You can have almost three weeks per year of downtime and still meet it. The number was chosen specifically to be feasible for home systems, but high enough to make it clear that we want always-on systems. Systems that are must less reliable than 95% just aren't very useful. In practice, most of our home-based nodes have availability on the order of 99%, and the co-located nodes are considerably higher -- some have never been down since they joined the grid ~2 years ago.
As for sharing a "few gigs"... if that's your goal then our grid isn't for you. It's intended for relatively high-volume backups -- a few hundred gigs, rather than a few gigs. If all you need to back up is a few gigs, there are a lot of very inexpensive and highly reliable network-based options out there. However, if you like the Tahoe approach, you're always free to find or build your own community-based grid with people who have similar needs to yours.
That sounds awesome, thanks for sharing it. I didn't see a quick explanation on the wiki: what are the minimum bandwidth and storage contributions?
Minimum storage is 500 GB, maximum is 1 TB. We don't have any stated bandwidth requirements, but you should probably have at least 5-6 Mbps downstream and (more importantly) 1-2 Mbps upstream. We'd prefer higher, obviously.
If I want to share photos with someone who's not on Facebook, I will just mark them "public"
What if you don't want to make them public? E-mail is probably a good choice, but it's a little less convenient to share the same stuff via two mechanisms.
An API like gimme_filesystem_changes_since_i_last_checked() is the kind of thing needed for an sane incremental backup program. I suspect Time Machine would do something like this (don't know for sure, since I'm a Linux guy...)
The Darwin kernel API for this is pretty nice. It doesn't track individual file changes, but instead just notifies of changes to directory contents. The notifications are sent to fseventsd, which consolidates multiple changes to the same directory that happen in a short period of time, then logs each directory that changed. Apps (like TimeMachine) can then ask which directories saw changes during arbitrary time intervals. It's then on the app to figure out which files changed and in what way, so it doesn't provide as much information as inotify, but by providing less granular information OS X can provide more complete data without consuming massive system resources.
maybe Google can harvest a bit of traffic data from their Android sets as well
If you have an Android device, go into Settings and look under "Location & security". There's an option there "Use location for Google Search". The description is "Let Google use your location to improve search results and other services". When you first power up a new Android device, it asks you whether you'd like to turn that on or not.
Because the GPS receiver is nearly always off (being a power hog), Wifi-based location is spotty (except in cities, where it's surprisingly accurate), and network-based location is so inaccurate, I doubt Google gets a great deal of useful traffic velocity data from people who just happen to have an Android phone in their car -- but Android devices that are actively being used for navigation would provide great traffic data. I don't know what percentage of drivers on the road are navigating with Android devices and have given Google permission to use their location, though.
Personally, I really like the traffic data provided by Google Navigator. It's very accurate, wherever it comes from. The only downside is that it is too limited; traffic data is usually only available on major highways.
The logical next step to make this even better, is to predict future traffic, rather than just reporting current traffic. It's really not very interesting to me to know what the traffic is like 80 miles ahead on my planned route. What I'd really like to know -- and what I'd really like Navigator's routing algorithm to know -- is what the traffic probably will be like when I get there. Mining traffic pattern data over time, correlating it with normal commuting patterns, special events, identifying accidents, etc., should make it possible to predict near-future traffic with considerable accuracy, excepting, of course, for unpredictable random events like accidents. Even there, though, as soon as an accident begins to cause traffic problems it might be identified, and re-routing performed. Perhaps other signals might be used, too... do radio traffic reporters have some digitally-accessible feed? Could Google get access to real-time accident information from emergency services?
I use a secure distributed grid. The software is an open source tool, Tahoe LAFS (http://tahoe-lafs.org). The grid is composed of ~15 servers contributed by different people all over the world. There are a half dozen servers in various locations in the US, about the same number in Europe, and the remainder in Russia and the Ukraine.
My files are AES256-encrypted on my machine, split into 13 pieces using Solomon-Reed coding, any five of which are sufficient to reconstruct my files, and then those 13 pieces are distributed to the servers in the grid. I run daily backups, but since uploads to the grid are idempotent, only the changed or new files are stored. I also run a bi-weekly "repair" operation which checks all of my files (all versions, from all backup runs) to see if any of their pieces are lost. If so, it reconstructs the missing pieces and deploys them to servers in the grid. The individual servers in the grid are fairly reliable, but problems do happen, so repair is important.
I get about 100 KBps net upload rate, so this isn't a good solution for backing up terabytes, and the occasional "surge" in my data generation (usually caused by a day of heavy photo-taking) often causes my "daily" backup to take a few days to run, but all in all it works very well.
Should my server ever die, I only need two pieces of information to get all of my data back: The grid "introducer" URL, which will allow me to set up a new node connected to the grid, and my root "dircap", which is a ~100-byte string containing the identifier and decryption key for the root directory of my archive. That directory contains the decryption keys for the files and directories it references.
Since this grid is all volunteer-based, the only cost to me for this backup solution is the hardware and bandwidth I provide to my grid (I provide 1 TB of disk and grid usage consumes a fairly small fraction of my Comcast connection), plus the time I spend administering my server and checking to see that my backup and repair processes are running. Oh, and I also contribute (a little) to the Tahoe LAFS project, but that's due to interest, not a requirement.
I'm very, very happy with this solution.
BTW, the grid could use another 20 nodes or so, if anyone is interested. There's a fair amount of trust required of new members to the grid, though, so it might take us a while to vet new members. The trust is required not because other members of the grid might have access to files that are not their own, but we need to verify that new members will behave appropriately -- providing their fair share of storage and bandwidth, and not consuming too much.
Anyone interested should check out the grid's policies and philosophy at: http://bigpig.org/twiki/bin/view/Main/WebHome. If all of that looks good, join the mailing list, introduce yourself and we'll consider allowing you to join the grid.
When an advertiser wants to target a very tight demographic, Google wants to be able to produce the maximum number of near-perfect matches.
It's a step beyond that, actually. Generally, advertisers don't even get much say in who their ads are presented to; it's on Google to figure out for a given ad who is likely to click on it, based not so much on traditional notions of demographic segmentation as on what Google's algorithms have learned about both the ad and the users.
(Disclaimer: I word for Google, but not on ads, so the above is just my very high-level understanding/guess of how the real-time ad auction works. I could be wrong.)
it could very well be Google aggregating the data and either making it public or selling it. I'm sure Google has a similar thing going on like Facebook where companies can pay extra $$$ to get unfettered access to the data as part of "we may share your data with interested third parties".
Google's privacy policy specifically states that Google does not share your information with third parties.
(Disclaimer: I'm a Google employee, but an engineer not an attorney, and this comment is based on my layman's reading of the privacy policy. It's also my honest understanding of what the policy means and intends.)
On phones the dedicated hardware would be a "Secure Element", an embedded smart card chip of the sort used to secure NFC transactions (e.g. Google Wallet). They're actually more secure than typical TPMs, and more secure than the ARM SoC "TrustZone". There are a small number of Android phone models that have SEs now, and more coming. Rumor has it that the iPhone5 will have NFC, which very likely means it will have an SE also.
There are 5040 4-digit pins, 151200 6-digit pins, 604800 7-digit pins, and 1814400 8-digit pins.
No, there are 10,000 4-digit PINs, 1,000,000 6-digit PINs, 10,000,000 7-digit PINs and 100,000,000 8-digit PINs. Unlike with patterns (as implemented by Android, at least), you're not restricted from re-using digits.
There are 362,880 9-dot patterns (use the whole pattern)
Not quite that many. You're assuming you can pick the nine dots in any sequence, but some patterns are impossible (or at least very difficult) because you can't get from one dot to the next in the pattern without touching a dot in between. It would be tedious, but not difficult, to enumerate the feasible set of patterns, and the likely set is even smaller, since people tend to choose connected sequences.
I'd say a longish pattern (6+ dots) is roughly equivalent to a four-digit PIN, but even a maximal-length pattern barely reaches the strength of a five-digit PIN.
Too true. Also, many people are also tempted to define entitlements as rights, such as the "right to housing", "right to adequate food and water", "right to high-speed Internet access", "right to a new car".
Defining what is and is not a fundamental human right isn't necessarily easy. Or, actually, it is very easy for me, and very easy for you, but what if we draw the lines in different places? Reaching consensus across a large group of people is almost impossible.
Just remember that the constitution does not grant you the right to fly either.
Actually the American founders though of that problem, and solved it via the Ninth Amendment
The enumeration in the Constitution of certain rights shall not be construed to deny or disparage others retained by the people.
This passage is really genius and its a great pity that the kind of intellectual governance that drafted it no longer exists in the US today.
That passage was James Madison's forlorn hope. He argued strongly that a Bill of Rights was a bad idea, because it could never enumerate everything that mattered and anything that was left out would have second-class status at best, or even be called a non-right because obviously if it were a right it would have been included. Only when it became clear that the absence of a Bill of Rights was threatening the Constitution, because the anti-Federalists were arguing that a "strong" federal government (remember that "strong" in those days meant something that was still only the barest shadow of today's juggernaut) would trample the rights of the people, did Madison relent and begin working on what we now know as the Bill of Rights.
The 9th and 10th were his attempt to stave off the disaster he'd predicted. History has shown that he was not wrong in his prediction of government running roughshod over non-enumerated rights. However, there's also not much proof that he was right in his prediction that not enumerating any rights would have worked better. He and the other Federalists really placed their trust in the states and the ability of the people to keep their own state governments from trampling their rights, but that hope proved just as vain, which is why the 14th amendment was eventually required.
Most low-level communications protocols have some framing overhead, so it's generally safer to assume that you can transmit one byte for every 10 bits. So 100 MBps requires a 1000 Mbps data rate. There's also some overhead at higher layers in the stack, such as Ethernet (or similar), IP, TCP and HTTP headers, though those are much less significant, consuming well under 1% of your effective bandwidth in most cases. Also keep in mind that we normally measure our files in power-of-two sizes (KiB, MiB, GiB) but communications rates are measured in power-of-10 bit rates. So 1000 Mbps = 100 MBps = ~95 MiBps, and 30 Gbps = 3 GBps = ~ 2.8 GiBps. Which would still be crazy fast.
You should check out murfie.com. You can buy a CD, but they keep the CD in their warehouse and you just download rips in the format of your choice. And you can often buy used CDs from other murfie.com users for far less than the normal price, and less than you'd pay for the same album on Google Music, Amazon or iTunes.
I don't need to copy files from one piece of hardware to another
Semi-OT, but I've found Google Music to be another nice solution (though one that does involve buying music). If you listen to music on PCs and Android devices it's really slick: Just upload all of your music (CDs, MP3s, AACs, etc.), up to 20K songs, and then it's all available on all your Android devices and any PC. For listening when you don't have a network connection you can have the Android app sync stuff to local storage ("make available offline"). When you do have a network, what's local vs what's streamed is transparent. Oh, no iOS app because Apple doesn't want competition. You can use Google Music on iOS via a web browser, but only for streamed music.
That said, I'm listening to Pandora right now, rather than my 15K-song Google Music collection. Why? Because it includes stuff I haven't bought and because it's low-effort. I use Pandora for most of my "background noise" listening and Google Music when I want to listen to specific songs, or when I'm off-line.
My 80-yr-old mother uses Linux. It was not "grandma simple" to install and set up (I did that for her), but she certainly has no trouble using it.
My father-in-law runs Linux because it's much easier for me to manage. Meaning, I set it up and it Just Works. Especially since I installed KDE and locked down the configuration so he can't accidentally change anything. Trying to manage a Windows system for him was just nightmarish.
Actually, I think for him the ideal OS might be ChromeOS (or Mozilla's spin on the same concept) -- nothing but a browser. Everything he uses his computer for is done through a browser, so anything else is just confusing cruft that can potentially get screwed up. I think this is increasingly true of an ever-larger set of the computer-using population.
What was useful was to find ways to make clear when I was and was not at work to help my family know what to expect
This is pretty much what was meant by the firewalls comment: not that you have to set inflexible work hours, but that you should make an effort to make a clear distinction and separation between the two.
My point was that you don't need to make the distinction time-based. I made it clear by being in my office. A colleague of mine had a hat that he wore. There are lots of ways to accomplish it, assuming your job is one that requires focus and doesn't tolerate interruption well. Many of the years I worked at home I was doing software development and needed big slabs of uninterrupted time, but I spent a couple of years doing technical sales support and found that I was very interruptible, except when on the phone.
Keep time. Software or good old watch, doesn't matter, but keep a record of the time you actually spend working. This will help you much, much more in keeping in line than some arbitrary "working hours". And it will help you in both directions, stopping you not only from working too little, but also from working too much.
This is important. Since I spend much of my day in EMACS anyway, I found using the clock-in/clock-out feature of org mode to be extremely useful. It not only allowed me to easily track total time working, but even to track time allocated to individual projects, to give me a sense of where I was spending my time.
Slashdot Mirror
95% uptime isn't that much, really. You can have almost three weeks per year of downtime and still meet it. The number was chosen specifically to be feasible for home systems, but high enough to make it clear that we want always-on systems. Systems that are must less reliable than 95% just aren't very useful. In practice, most of our home-based nodes have availability on the order of 99%, and the co-located nodes are considerably higher -- some have never been down since they joined the grid ~2 years ago.
As for sharing a "few gigs"... if that's your goal then our grid isn't for you. It's intended for relatively high-volume backups -- a few hundred gigs, rather than a few gigs. If all you need to back up is a few gigs, there are a lot of very inexpensive and highly reliable network-based options out there. However, if you like the Tahoe approach, you're always free to find or build your own community-based grid with people who have similar needs to yours.
That sounds awesome, thanks for sharing it. I didn't see a quick explanation on the wiki: what are the minimum bandwidth and storage contributions?
Minimum storage is 500 GB, maximum is 1 TB. We don't have any stated bandwidth requirements, but you should probably have at least 5-6 Mbps downstream and (more importantly) 1-2 Mbps upstream. We'd prefer higher, obviously.
Well, looks like it's not suitable for home users at all. :(
I use it at home :-)
If I want to share photos with someone who's not on Facebook, I will just mark them "public"
What if you don't want to make them public? E-mail is probably a good choice, but it's a little less convenient to share the same stuff via two mechanisms.
An API like gimme_filesystem_changes_since_i_last_checked() is the kind of thing needed for an sane incremental backup program. I suspect Time Machine would do something like this (don't know for sure, since I'm a Linux guy...)
The Darwin kernel API for this is pretty nice. It doesn't track individual file changes, but instead just notifies of changes to directory contents. The notifications are sent to fseventsd, which consolidates multiple changes to the same directory that happen in a short period of time, then logs each directory that changed. Apps (like TimeMachine) can then ask which directories saw changes during arbitrary time intervals. It's then on the app to figure out which files changed and in what way, so it doesn't provide as much information as inotify, but by providing less granular information OS X can provide more complete data without consuming massive system resources.
maybe Google can harvest a bit of traffic data from their Android sets as well
If you have an Android device, go into Settings and look under "Location & security". There's an option there "Use location for Google Search". The description is "Let Google use your location to improve search results and other services". When you first power up a new Android device, it asks you whether you'd like to turn that on or not.
Because the GPS receiver is nearly always off (being a power hog), Wifi-based location is spotty (except in cities, where it's surprisingly accurate), and network-based location is so inaccurate, I doubt Google gets a great deal of useful traffic velocity data from people who just happen to have an Android phone in their car -- but Android devices that are actively being used for navigation would provide great traffic data. I don't know what percentage of drivers on the road are navigating with Android devices and have given Google permission to use their location, though.
Personally, I really like the traffic data provided by Google Navigator. It's very accurate, wherever it comes from. The only downside is that it is too limited; traffic data is usually only available on major highways.
The logical next step to make this even better, is to predict future traffic, rather than just reporting current traffic. It's really not very interesting to me to know what the traffic is like 80 miles ahead on my planned route. What I'd really like to know -- and what I'd really like Navigator's routing algorithm to know -- is what the traffic probably will be like when I get there. Mining traffic pattern data over time, correlating it with normal commuting patterns, special events, identifying accidents, etc., should make it possible to predict near-future traffic with considerable accuracy, excepting, of course, for unpredictable random events like accidents. Even there, though, as soon as an accident begins to cause traffic problems it might be identified, and re-routing performed. Perhaps other signals might be used, too... do radio traffic reporters have some digitally-accessible feed? Could Google get access to real-time accident information from emergency services?
Lots of possibilities here...
I use a secure distributed grid. The software is an open source tool, Tahoe LAFS (http://tahoe-lafs.org). The grid is composed of ~15 servers contributed by different people all over the world. There are a half dozen servers in various locations in the US, about the same number in Europe, and the remainder in Russia and the Ukraine.
My files are AES256-encrypted on my machine, split into 13 pieces using Solomon-Reed coding, any five of which are sufficient to reconstruct my files, and then those 13 pieces are distributed to the servers in the grid. I run daily backups, but since uploads to the grid are idempotent, only the changed or new files are stored. I also run a bi-weekly "repair" operation which checks all of my files (all versions, from all backup runs) to see if any of their pieces are lost. If so, it reconstructs the missing pieces and deploys them to servers in the grid. The individual servers in the grid are fairly reliable, but problems do happen, so repair is important.
I get about 100 KBps net upload rate, so this isn't a good solution for backing up terabytes, and the occasional "surge" in my data generation (usually caused by a day of heavy photo-taking) often causes my "daily" backup to take a few days to run, but all in all it works very well.
Should my server ever die, I only need two pieces of information to get all of my data back: The grid "introducer" URL, which will allow me to set up a new node connected to the grid, and my root "dircap", which is a ~100-byte string containing the identifier and decryption key for the root directory of my archive. That directory contains the decryption keys for the files and directories it references.
Since this grid is all volunteer-based, the only cost to me for this backup solution is the hardware and bandwidth I provide to my grid (I provide 1 TB of disk and grid usage consumes a fairly small fraction of my Comcast connection), plus the time I spend administering my server and checking to see that my backup and repair processes are running. Oh, and I also contribute (a little) to the Tahoe LAFS project, but that's due to interest, not a requirement.
I'm very, very happy with this solution.
BTW, the grid could use another 20 nodes or so, if anyone is interested. There's a fair amount of trust required of new members to the grid, though, so it might take us a while to vet new members. The trust is required not because other members of the grid might have access to files that are not their own, but we need to verify that new members will behave appropriately -- providing their fair share of storage and bandwidth, and not consuming too much.
Anyone interested should check out the grid's policies and philosophy at: http://bigpig.org/twiki/bin/view/Main/WebHome. If all of that looks good, join the mailing list, introduce yourself and we'll consider allowing you to join the grid.
Google has a strong history of not selling personal information.
More than a history. Google's privacy policy explicitly states that Google does not share personal information with third parties.
Cool! Very interesting. Care to share your code?
When an advertiser wants to target a very tight demographic, Google wants to be able to produce the maximum number of near-perfect matches.
It's a step beyond that, actually. Generally, advertisers don't even get much say in who their ads are presented to; it's on Google to figure out for a given ad who is likely to click on it, based not so much on traditional notions of demographic segmentation as on what Google's algorithms have learned about both the ad and the users.
(Disclaimer: I word for Google, but not on ads, so the above is just my very high-level understanding/guess of how the real-time ad auction works. I could be wrong.)
it could very well be Google aggregating the data and either making it public or selling it. I'm sure Google has a similar thing going on like Facebook where companies can pay extra $$$ to get unfettered access to the data as part of "we may share your data with interested third parties".
Google's privacy policy specifically states that Google does not share your information with third parties.
(Disclaimer: I'm a Google employee, but an engineer not an attorney, and this comment is based on my layman's reading of the privacy policy. It's also my honest understanding of what the policy means and intends.)
On phones the dedicated hardware would be a "Secure Element", an embedded smart card chip of the sort used to secure NFC transactions (e.g. Google Wallet). They're actually more secure than typical TPMs, and more secure than the ARM SoC "TrustZone". There are a small number of Android phone models that have SEs now, and more coming. Rumor has it that the iPhone5 will have NFC, which very likely means it will have an SE also.
There are 5040 4-digit pins, 151200 6-digit pins, 604800 7-digit pins, and 1814400 8-digit pins.
No, there are 10,000 4-digit PINs, 1,000,000 6-digit PINs, 10,000,000 7-digit PINs and 100,000,000 8-digit PINs. Unlike with patterns (as implemented by Android, at least), you're not restricted from re-using digits.
There are 362,880 9-dot patterns (use the whole pattern)
Not quite that many. You're assuming you can pick the nine dots in any sequence, but some patterns are impossible (or at least very difficult) because you can't get from one dot to the next in the pattern without touching a dot in between. It would be tedious, but not difficult, to enumerate the feasible set of patterns, and the likely set is even smaller, since people tend to choose connected sequences.
I'd say a longish pattern (6+ dots) is roughly equivalent to a four-digit PIN, but even a maximal-length pattern barely reaches the strength of a five-digit PIN.
Too true. Also, many people are also tempted to define entitlements as rights, such as the "right to housing", "right to adequate food and water", "right to high-speed Internet access", "right to a new car".
Defining what is and is not a fundamental human right isn't necessarily easy. Or, actually, it is very easy for me, and very easy for you, but what if we draw the lines in different places? Reaching consensus across a large group of people is almost impossible.
Actually the American founders though of that problem, and solved it via the Ninth Amendment The enumeration in the Constitution of certain rights shall not be construed to deny or disparage others retained by the people. This passage is really genius and its a great pity that the kind of intellectual governance that drafted it no longer exists in the US today.
That passage was James Madison's forlorn hope. He argued strongly that a Bill of Rights was a bad idea, because it could never enumerate everything that mattered and anything that was left out would have second-class status at best, or even be called a non-right because obviously if it were a right it would have been included. Only when it became clear that the absence of a Bill of Rights was threatening the Constitution, because the anti-Federalists were arguing that a "strong" federal government (remember that "strong" in those days meant something that was still only the barest shadow of today's juggernaut) would trample the rights of the people, did Madison relent and begin working on what we now know as the Bill of Rights.
The 9th and 10th were his attempt to stave off the disaster he'd predicted. History has shown that he was not wrong in his prediction of government running roughshod over non-enumerated rights. However, there's also not much proof that he was right in his prediction that not enumerating any rights would have worked better. He and the other Federalists really placed their trust in the states and the ability of the people to keep their own state governments from trampling their rights, but that hope proved just as vain, which is why the 14th amendment was eventually required.
If you're 6' 5", it's likely there aren't many cars in which you could lock your leg in extension, even with the seat all the way back.
It puzzles me why a population would choose the "freedom" to not wear a seatbelt and then happily accept the consequence
Are you trolling?
Seat belts are mandatory in the US, with the sole exception of New Hampshire, where they're compulsory for minors but not adults.
Our airbags are known as "SRS" - the Supplementary Restraint System. They don't explode at you with anywhere near the force of the US ones
Cite?
8 bits in a Byte
Not really.
Most low-level communications protocols have some framing overhead, so it's generally safer to assume that you can transmit one byte for every 10 bits. So 100 MBps requires a 1000 Mbps data rate. There's also some overhead at higher layers in the stack, such as Ethernet (or similar), IP, TCP and HTTP headers, though those are much less significant, consuming well under 1% of your effective bandwidth in most cases. Also keep in mind that we normally measure our files in power-of-two sizes (KiB, MiB, GiB) but communications rates are measured in power-of-10 bit rates. So 1000 Mbps = 100 MBps = ~95 MiBps, and 30 Gbps = 3 GBps = ~ 2.8 GiBps. Which would still be crazy fast.
Yes, but AFAIK Android's voice dictation is done on the phone
No, it isn't. It's done in the cloud. If you don't have data service, voice dictation doesn't work.
You should check out murfie.com. You can buy a CD, but they keep the CD in their warehouse and you just download rips in the format of your choice. And you can often buy used CDs from other murfie.com users for far less than the normal price, and less than you'd pay for the same album on Google Music, Amazon or iTunes.
I don't need to copy files from one piece of hardware to another
Semi-OT, but I've found Google Music to be another nice solution (though one that does involve buying music). If you listen to music on PCs and Android devices it's really slick: Just upload all of your music (CDs, MP3s, AACs, etc.), up to 20K songs, and then it's all available on all your Android devices and any PC. For listening when you don't have a network connection you can have the Android app sync stuff to local storage ("make available offline"). When you do have a network, what's local vs what's streamed is transparent. Oh, no iOS app because Apple doesn't want competition. You can use Google Music on iOS via a web browser, but only for streamed music.
That said, I'm listening to Pandora right now, rather than my 15K-song Google Music collection. Why? Because it includes stuff I haven't bought and because it's low-effort. I use Pandora for most of my "background noise" listening and Google Music when I want to listen to specific songs, or when I'm off-line.
My 80-yr-old mother uses Linux. It was not "grandma simple" to install and set up (I did that for her), but she certainly has no trouble using it.
My father-in-law runs Linux because it's much easier for me to manage. Meaning, I set it up and it Just Works. Especially since I installed KDE and locked down the configuration so he can't accidentally change anything. Trying to manage a Windows system for him was just nightmarish.
Actually, I think for him the ideal OS might be ChromeOS (or Mozilla's spin on the same concept) -- nothing but a browser. Everything he uses his computer for is done through a browser, so anything else is just confusing cruft that can potentially get screwed up. I think this is increasingly true of an ever-larger set of the computer-using population.
This article mentions it.
This is pretty much what was meant by the firewalls comment: not that you have to set inflexible work hours, but that you should make an effort to make a clear distinction and separation between the two.
My point was that you don't need to make the distinction time-based. I made it clear by being in my office. A colleague of mine had a hat that he wore. There are lots of ways to accomplish it, assuming your job is one that requires focus and doesn't tolerate interruption well. Many of the years I worked at home I was doing software development and needed big slabs of uninterrupted time, but I spent a couple of years doing technical sales support and found that I was very interruptible, except when on the phone.
Keep time. Software or good old watch, doesn't matter, but keep a record of the time you actually spend working. This will help you much, much more in keeping in line than some arbitrary "working hours". And it will help you in both directions, stopping you not only from working too little, but also from working too much.
This is important. Since I spend much of my day in EMACS anyway, I found using the clock-in/clock-out feature of org mode to be extremely useful. It not only allowed me to easily track total time working, but even to track time allocated to individual projects, to give me a sense of where I was spending my time.