For When You Can't Have The Real Thing
[ start | index | login ]
start > Household Computing

Household Computing

Created by dave. Last edited by dave, 12 years and 334 days ago. Viewed 3,288 times. #3
[diff] [history] [edit] [rdf]
labels
attachments
Thoughts on Household Computing

What is Household Computing?

Household computing is literally what the name says it is: planning, implementing, and operating the computers that end up in the home.

Many homes now have multiple computers operating in them. The advent of widely available DSL and cable high-speed internet has lead to these computers being networked together in order to share access to the internet, shared storage and printers, and other resources.

Most of these networks end up growing in an ad-hoc manner. A computer is purchased, then a replacement is added and the original handed down to another member of the household, then networking is added, then storage… the result is a mess.

To speak of "computing", implying some form of management, may seem like an irrelevancy in this kind of environment; however, some form of management, however minimal, must occur in any environment. Someone must make some of the arbitrary decisions regarding the network architecture (for example, the IP space the internal network will use, the location and configuration of the DSL firewall, the keys to use in the wireless configuration; the list goes on and on).

Similarly, there is some form of ad-hoc "support staff", usually the most technically inclined family member, who draws the task of troubleshooting and repairing the family's computers when problems occur.

Basic Services

When considering household computing, the starting points are the same as for any corporate network:

  1. What are we trying to accomplish?
  2. How will the computers help us accomplish these goals?
  3. How will we use the computers?
  4. How much are we willing to spend (in both money and time) to make this happen?
For many households, the answer to question two will direct the basic services that the network needs to offer. For example:
  • Internet Tone: the presence (or availability) of access to the internet. This is usually provided through a DSL or cable connection, shared through a (wired or wireless) network through the house to all computers, but could be reduced to the basics of this single computer has a modem on it, through which we will connect to the internet.
  • Email
  • File Sharing
  • User Account harmonization: Usernames and passwords are available across a subset, or all, of the machines on the network; this can be extended so that the same username/password is used for file sharing, email, and other services.
  • User Account Environment Consistency: User accounts will look the samea cross multiple machines on the network.
  • Internet Hosting such as web or ftp site hosting
  • Centralized Backups consisting of anything from backups of the available services to regulated backups of all systems on the network.
  • Network Configuration and Management Services ranging from DHCP auto configuration and DNS services, up to and including active performance and system health monitoring.

Computing To Go: The Laptop Invasion

More recently, the newer computers arriving in the household are disproportionately laptop computers. Laptops differ from desktop/server systems in a couple of important ways:

  • they are typically reserved for a single user; and
  • due to their transient nature, their resources are not shared with the rest of the network.
The implications of these differences lead to some implications for network design.

To Serve or Not To Serve; That Is The Question

There are two options when making a household network: do you provide services to your network users, or do you treat them as standalone, independent client systems.

There is one school of thought which says that if services are provided on the network, the network gains from the standardization: all files should be stored on system $x; all mail comes from $y. User accounts, passwords, and environments can be standardized, leading to a greater degree of user environmental redundancy in the event that one of the end stations fails (ie there is a greater chance that a user can log into an arbitrary other system and resume work with a minimum of data loss and inconvenience).

There is a second school of thought, brought to my attention by >>Mr. Jonathan Schwartz. Mr. Schwartz >>states:

But I do run into problems, given my refusal to run a server in my home. Yes, I refuse to run a server. I know it's heresy for someone in my position (especially someone with 5+ desktops), but my view is regular users shouldn't run servers in their homes.

The logic behind this is:

  • there are free (or affordable services) on the web to do just about anything that you might like a local server to do;
  • for the vast majority of end users, those services will be run far better than a home user could provide; and
  • a service over the web will be available from anywhere, not just when the user is at home;
...therefore, most users would be better off using over-the-web services.

The typical example of such a service would be HotMail (or Google Mail, or whatever). This gives you an email inbox that is available from any web browser in the world, no matter where you are.

I favor the first approach, because:

  • I am a network administrator. Administrators are usually paranoid, and I don't trust anyone else with my data.
  • I am a network administrator, and I know better than the average user how to run and provide services.
  • Remote service or not, I am the one my wife (and eventually, son) will come to when there are problems. Controlling the service means I have high resolution control over both ends of a potential problem which will make troubleshooting easier.
no comments | post comment
This is a collection of techical information, much of it learned the hard way. Consider it a lab book or a /info directory. I doubt much of it will be of use to anyone else.

Useful:


snipsnap.org | Copyright 2000-2002 Matthias L. Jugel and Stephan J. Schmidt