dcsimg

Thin Client Computing, Part One

Thin clients offer an approach to computing with a number of advantages over the more common desktop computer approach. Learn how to enable it.

Thin client computing has been a buzzphrase for the past few years. In a thin client network, users sit at low-powered machines and run programs on more powerful central computers.

As described shortly, this approach to computing offers certain advantages over the more common desktop computer approach. This month’s column looks at the basic principles of thin client computing and presents basic information on the server side of the thin client equation. Next time I’ll describe the client side.

Why Use Thin Client Computing?

The idea behind thin client computing is one of centralization: A single computer, or perhaps a small” farm” of computers, holds all user accounts and most of the programs that users run. Users access these systems using less powerful systems– the thin clients. This approach provides several advantages over the more conventional method of providing each user with a fully-equipped desktop computer:

  • The thin clients are inexpensive, minimizing costs and perhaps enabling continued use of old computers as thin clients.
  • The thin clients hold simple software packages, reducing administrative requirements to maintain them.
  • The thin clients can be diskless and can use less power-hungry CPUs, minimizing power consumption, noise, and cooling costs.
  • The thin clients don’t need direct Internet access, reducing security risks and enabling them to run on private IP addresses, thus reducing the need for public IP addresses.
  • Users can use any thin client to access their own accounts and files. This is handy in public computing centers or when users move from one work space to another.
  • Upgrades to most software packages are restricted to the server systems, reducing administrative effort.
  • Backups are simplified; only the servers need to be backed up.

Of course, thin client computing isn’t without its drawbacks. The servers that power thin clients must be more powerful than the average desktop system, since each one will host several users. As a general rule of thumb, count on about 75-100MHz of CPU power and 50MB of RAM per client, plus a baseline of 512MB of RAM to start. Your exact needs will vary depending on your uses, though.

Computing reliability is tied to the server (s). When a user’s fat client fails, that user is disable– but the rest of the office can keep working. If an office using thin clients experiences a server failure, all users will be affected. Picking reliable hardware and having backup hardware ready can mitigate problems caused by hardware failures. Keeping server software backups is important, as well.

The network load is likely to be higher in a thin client configuration than in a typical desktop-using office.

Since thin client computing requires servers to accept remote logins, thin client computing introduces a potential security hole.

Access to local hardware (CD-ROM drives, printers, USB devices, etc.) can be complicated. Some thin client packages are preconfigured to handle some common local hardware, but this isn’t always the case. Finally, CPU-intensive and display-intensive programs are poorly matched to thin client configurations.

As a general rule of thumb, thin client computing works best in situations where users run typical office programs, such as e-mail, Web browsing, word processing, and light spreadsheet use. Tools that are very CPU-intensive or that make heavy use of the display (streaming videos, games, and scientific simulations, for instance) don’t work well because they demand too much of the server or of the network.

Servers Required to Support Thin Clients

The ideal setup for a network that uses thin clients involves configuring the thin clients to boot from the network. This enables thin clients to run without any local storage. Not all computers support network boots, though, so you may need floppy disks or even CD-ROMs on some or all of your thin clients to get the process started.

In order to boot thin clients from the network, you’ll need to run two server protocols: The Dynamic Host Configuration Protocol (DHCP), which assigns IP addresses to clients, and the Trivial File Transfer Protocol (TFTP), which delivers boot files to thin clients. Neither DHCP nor TFTP is strictly required in a thin client environment, but they are needed for network booting. On all but very large networks, only one system needs to be configured as a server for each of these protocols.

Of course, you’ll also need to configure X or Virtual Network Computing (VNC) to handle remote logins. You might have just one or many computers running remote login protocols. DHCP, TFTP, and remote login protocols need not all run on a single computer, but they can do so if it’s convenient.

Configuring DHCP

DHCP configuration is complex enough that I can’t describe the whole process here. If you’re not already using a Linux DHCP server, you’ll have to research basic Linux DHCP configuration before you proceed, learn to configure your non-Linux DHCP server to do the tasks I describe, or forego DHCP configuration for thin clients. You can still use thin clients without the help of DHCP, but you may need to tell clients where to find your TFTP server or even outfit them with complete software packages locally (on CD-Rs or hard disks).

The main point of DHCP configuration for thin clients is to enable the DHCP features that point clients to a TFTP server. If you’re using the popular Internet Software Consortium (ISC) DHCP server, you’ll probably find its main configuration file in /etc/dhcpd.conf. This file includes a series of global options followed by one or more subnet declarations, which define options for specific subnets. To support thin clients, you’ll want to ensure that two options are set, either globally or as part of specific subnet declarations:

option tftp-server-name "192.168.1.1";
filename "thinstation.nbi";

The tftp-server-name option points clients to a TFTP server. This line is extremely important if you intend to boot thin clients from the network. Note that the name must be enclosed in quotation marks, even if you specify it as an IP address.

The filename option provides the name of an OS image file in the TFTP server’s directory (described shortly). This option should be set to a name that’s appropriate for whatever thin client software you intend to run. The preceding example uses "thinstation.nbi", which is suitable for the ThinStation client described next month.

Some thin clients require one or both of two additional options:

allow bootp;
option x-display-manager 192.168.1.1;

These options enable the older BootP protocol, which is similar to DHCP, and point the client to an X server. Neither of these options is required for the ThinStation client software, but you may need these options if you use other thin clients.

Of course, you should adjust the values of all of these options for your own network. You can provide all of these options as globals, or in subnet, host, or other more specific declaration blocks. You can use this fact to provide a default configuration or tweak the configuration for individual clients or groups of clients. For instance, you can mix and match dedicated thin clients, which require their own software, with ThinStation clients.

Remember to restart your DHCP server once you’ve changed its configuration. Typically, you can do this by passing the restart option to a SysV startup script, like /etc/init.d/dhcpd restart.

Configuring TFTP

TFTP is delivered with most Linux distributions, or you can download a copy from http://www.kernel.org/pub/software/network/tftp/. Linux TFTP packages typically ship with a file called /etc/xinetd.d/tftp, which launches the TFTP daemon via the xinetd server. Chances are you’ll have to edit the /etc/xinetd.d/tftp file and change the disable line to read disable=no. You may also need to set the server_args line; it should use the -s option and point to a directory in which boot files are to be stored:

server_args=-s /tftpboot

Once you’ve edited /etc/xinetd.d/tftp, you should create the directory you’ve specified, if it doesn’t already exist. You should then restart the xinetd daemon. You can usually do this by typing /etc/init.d/xinetd restart, although the exact path to the startup script may vary depending on your distribution.

With the TFTP server running, you must still populate its file directory with the thin client software. Although the files reside on the TFTP server computer, this is really a client issue, so I describe it in more detail next month.

Configuring X and XDMCP

X is peculiar because it uses client and server roles that seem backwards to most people; you sit at the server computer and use X clients that are remote. Thus, in a thin client configuration, you don’t need to be concerned with X server configuration on the powerful host computer. Instead, you’ll run the X server on the thin client computer. In most cases, X configuration on the thin client is fairly straightforward, and I describe it next month.

You do, however, need to configure a login protocol server for X. This protocol is XDMCP. If your environment hosts multiple systems that a user might access, you’ll need to configure XDMCP on each of them.

Most Linux distributions ship with an XDMCP server. The most common are the X Display Manager (XDM), the KDE Display Manager (KDM), and the GNOME Display Manager (GDM). On a desktop computer, one of these programs, or something similar, manages the GUI login screen. Most Linux distributions, however, configure XDMCP to block outside access attempts. This is a useful security feature for a typical desktop computer, but it just won’t do if thin clients are to access the computer using X. Thus, you’ll have to loosen the security restrictions on your system.

The first trick is in finding which XDMCP server you’re running on the computer you intend to have accept thin client logins. Try typing ps ax|grep dm. This command shows you all processes with the string dm in their names. You’ll probably notice xdm, kdm, or gdm in the output. If you don’t, then the system isn’t configured to start up in GUI mode or you’re using some other XDMCP server.

If you’re running XDM, you can configure it to accept remote logins by editing two or three files. The first of these is /etc/X11/xdm/xdm-config. Locate the following line:

DisplayManager.requestPort: 0

Change the 0 in this line to 177 to have XDM listen for remote access attempts. The second file you must edit is /etc/X11/xdm/Xaccess. This file will probably include the following two lines:

# *
# * CHOOSER BROADCAST

Remove the hash marks (#) at the start of these lines to tell the computer to accept remote accesses and to generate a list of available remote hosts, respectively. You can substitute a wildcard matching your network, such as *.example.com, for the simple asterisk (*) in these lines, to limit access to your network. Finally, the third XDM file you may need to edit is /etc/X11/xdm/Xservers. Details vary greatly from one distribution to another, but you’ll probably find a line that resembles the following:

:0 local /usr/X11R6/bin/X -nolisten tcp -br vt7

The -nolisten tcp option prevents X from making remote connections. This won’t affect a thin client’s ability to connect to the computer, but it will prevent you from accessing other X servers from the affected system. Thus, you may want to edit it out. If you don’t want X to run locally at all, you should comment out this line entirely. This will cause XDM to accept remote connections but not to launch X locally.

In theory, KDM configuration is similar to that of XDM; however, you’ll need to track down the equivalent configuration files, which vary greatly in location from one distribution to another. In practice, KDM is also much more finicky than XDM, so configuring KDM can be frustrating. Be aware that you’ll probably need to edit a file called kde-config or kdm-config rather than xdm-config. An additional configuration file, kdmrc, may also require editing. Locate the [Xdmcp] section of this file and edit it so that it includes these lines:

Enable=true
Port=177

GDM uses the gdm.conf configuration file, which usually resides in /etc/X11/gdm. This file is similar to the kdmrc file, and you must make the changes just described to the [Xdmcp] section of this file. Alternatively, you can use the gdmsetup utility to make the changes using a GUI tool.

Whatever XDMCP server you use, you must restart it before the changes you’ve made take effect. This will shut down your current X session, so you should save your work, close your open programs, and log out. On many Linux systems, changing to runlevel 3 and then back to runlevel 5 will restart the XDMCP server. Type telinit 3 followed by telinit 5 to do this. On others, you can restart the XDMCP server by typing /etc/init.d/xdm restart (you may need to substitute kdm or gdm for xdm on some distributions).

Configuring VNC

If you want to use VNC rather than X, you can do so, but configuration can be tricky; X is generally superior if your thin clients support it. Two popular Linux VNC servers are RealVNC (http://www.realvnc.com) and TightVNC (http://www.tightvnc.com); you’ll run one of these on your login host. Under Linux, VNC is designed to be run by an individual user, and the login connection then accesses that user’s account directly. This approach may be adequate for some small-scale operations, but for greatest flexibility, it’s best to link the VNC server to an XDMCP server. This way, remote users will see a Linux login screen when they connect, so any user with an account may enter a username and password to access the computer.

This configuration requires you to make the changes to the XDMCP setup just described. You can then create a xinetd configuration file, say /etc/xinetd.d/vnc, to launch the VNC server:

service vnc-800x600
{
 disable	= no
 socket_type	= stream
 protocol	= tcp
 wait		= no
 user		= nobody
 server		= /usr/bin/Xvnc
 server_args	= -inetd -query localhost \
    -once -geometry 800x600 -depth 24 \
    -fp /usr/share/fonts/local/,/usr/share/fonts/misc/
}

This configuration works for a TightVNC server on a Gentoo Linux system. Unfortunately, the details of VNC configuration vary from one VNC server to another. Thus, you may need to read the man pages and experiment to find a configuration that works. This particular configuration relies on an entry in /etc/services:

vnc-800x600 5901/tcp

This entry assigns TCP port 5901 to the service name vnc-800x600. On the client side, you’ll need to tell the thin client to connect to this port.

Next: Client Configuration

At this point, you should have one or more server computers configured to support thin clients, but without thin client software installed. Next month I describe how to remedy this important omission, with information on configuring the ThinStation client software to work with the Linux clients you’ve just configured.

Comments on "Thin Client Computing, Part One"

thinstation.mike

As one of the people in the Thinstation team, I urge you to test NX as an alternative to X and VNC (nomachine.com or FreeNX). This protocol is supportet by Thinstation, and in my opinion way superior.

Thanks for this article anyway. More people need to know about SBC.

Mike

Reply
wcn00

I’m not so much a “thin client” user as a remote desktop user. I found that remote X or VNC sessions over the internet (the best you can buy where I live) is unacceptably slow. I currently use NX and it is ok, but experiences regular stalls that I have to kill it to get out of.
For thin client or remote desktop to be feasible the xorg must make dramatic improvements in the remote protocols…
wcn

Reply
eworthy

wcn00 said the keywords ‘remote desktop’. However he then ruined it by talking about an over broadband experience.

The power of SBC/thin client is in the LAN. The client can be virtually any old box with a NIC. Customized fancy, static, thin-client boxes need not apply.
How many of you have old retired boxes in the basement? Break them out and repurpose them as thin clients attached to your newest hottest machine set-up as a terminal server. You now have as many hot machines as you have boxes. Sweet!
This will keep tens of thousands of machines out of the landfill or the clutches of unethical recyclers who just foist our pollution problems on the third world.
Did I mention that the server could even be running that other legacy operating system and you could RDP to it? Check out on the net, the various ways that this can be done with multiple concurrent connections even on the non-server versions.
By the way, thinstation, is awesome. Go, thinstation team, go.

Reply
dresserd

If you are considering Linux thin clients, I can highly recommend the Linux Terminal Server Project (LTSP.org) It is a very active open source project to make Linux thin clients easy to implement and manage.

Reply
chuntera

About ten years ago, I used LBX(Low Bandwidth X – http://en.wikipedia.org/wiki/LBX) for remote X seesions. Is this still useful ? How does in compare to VNC or FreeNX ?

Thanks,

–Chris

Reply
rexterd

I wish you can include thin client (LTSP) on a wireless environment.

Reply
billtodd

Let’s take up some of your points in the order in which they occur:

1. “Thin clients are inexpensive,” eh? Compared to what? The kind of thin client that you describe sounds very much like a modest PC, and if indeed thin clients are primarily good only for things like “e-mail, Web browsing, word processing, and light spreadsheet use”, then the same hardware that can run the thin client (including the kind of obsolete hardware that you suggest recycling – certainly back to Pentium IIs and K6s, anyway) could run those applications locally with entirely adequate performance – and with no need for the supplementary (and considerably more expensive) kind of application servers that you describe, nor the significantly added complexity of such a configuration.

2. “The thin clients hold simple software packages, reducing administrative requirements to maintain them” – but not eliminating those costs, plus the costs of maintaining all the server software. The key point here is that you don’t need centralized computation to centralize software maintenance: you just need central (sharable) storage – so the way to minimize software administration is to centralize the software, including that required to run the client platforms (at which point thin clients are at a slight disadvantage compared with normal clients, since you have to maintain not only the ‘real’ application software that users need but the additional thin-client and special server software as well).

3. “The thin clients can be diskless and can use less power-hungry CPUs”? No advantage there either, I’m afraid: fat clients can also be diskless, and if seldom taxed beyond your set of thin-client-appropriate applications that I quoted above can use equally power-efficient CPUs.

4. “The thin clients don’t need direct Internet access, reducing security risks and enabling them to run on private IP addresses, thus reducing the need for public IP addresses.” Er, don’t most LANs (including those running fat clients) use private IP addresses and NAT to access the Internet anyway? And exactly what kinds of security risks are reduced (I can certainly imagine special server-side software that could impose additional constraints on Internet access, but not without significantly limiting normal activities)?

5. “Users can use any thin client to access their own accounts and files” – but of course they can with fat clients too, as long as the *storage* is centralized.

6. “Upgrades to most software packages are restricted to the server systems, reducing administrative effort.” Yet again, you can do this with fat clients as well, as long as the storage is centralized.

7. “Backups are simplified; only the servers need to be backed up.” Servers don’t get backed up: data does. And as long as the data is centralized, it doesn’t matter whether it’s accessed by thin clients or by fat clients – backing it up can still be centralized.

8. “As a general rule of thumb, count on about 75-100MHz of CPU power and 50MB of RAM per client, plus a baseline of 512MB of RAM to start.” Oh, dear: I suppose if you configure your server so sparsely you may manage to start, but you’ll probably never get out of first gear. These figures are far too meager even to power a modest file server, let alone an application server (unless only a small percentage of the clients are ever active at once).

9. “When a user’s fat client fails, that user is disable” (sic) – unless, of course, that user’s fat client is operating on centralized storage, in which case the user just moves over to another fat client and soldiers on – the same as would happen with a thin client.

10. “If an office using thin clients experiences a server failure, all users will be affected” – well, yuh. Interestingly enough, however, if an office using fat clients to access centralized storage experiences a server failure, it’s entirely feasible to ensure that *no* users will be affected, because fail-over shared NAS is relatively mature (and inexpensive) technology.

11. “CPU-intensive and display-intensive programs are poorly matched to thin client configurations.” Indeed they are – whereas using fat clients and centralized storage you have the option to throw some more robust clients into the mix to handle such activity when required.

What kind of death-wish would inspire people to forsake the greatest benefits of the PC revolution for a return to the worst aspects of time-sharing? Processor cycles (even x86 processor cycles, for those who might consider using embedded processors instead for thin clients) are dirt-cheap compared with the cost of even a modest thin client, and having such cycles private to your own desktop to run applications and your screen processing frees you from adverse impact from the activities of your co-workers. By contrast, processor cycles are *not* dirt-cheap in servers configured to serve users (and their applications and screen processing) en masse: they don’t enjoy the benefits of commodity-level volume and consequent pricing, so purchasers will tend to skimp (figuring that if most users aren’t bothered too much most of the time that’ll be good enough).

And you don’t *need* to sacrifice such personal performance for ease of management, if you just centralize the storage rather than the data processing. You can even avoid most of the rare cases where storage access over the LAN would be a bottleneck by configuring high-intensity storage use applications like very active databases as server applications which the fat clients use remotely.

Some special support might be required to create such an environment using Windows, which just wasn’t designed with an eye toward the clean separation of system and user environments that Unix grew up supporting (and to give time-sharing its due that’s something we owe it). But it should be fairly natural for Linux – so why are you flirting with thin clients at all?

- bill

Reply
keith2

Hi there. I have been running an Ubuntu/LTSP lab with 26 thin clients in a primary school (ages 4 to 13) since January 2004 – This was a Shuttleworth Foundation initiative). We have a P4 Server (3.0GHz/4G RAM) which, when it doesn’t freeze up (we suspect that this is related to a motherboard issue and not a Linux issue), is awesome. I hear what Bill says and it is all relevant. There are sometimes reasons why folks may wish to use a thin client setup. In our case we wished to create a situation in which the kids didn’t have access to hard drives, CD/DVD’s or floppy drives. Maintenance is limited to Server backups. Another reason is the MASSIVE MASSIVE saving on Software costs per machine!!)

The really, really neat thing for me is that I can manipulate the kid’s data so easily – it is all in /home/learners/Grade7, etc.. (I know that this can also be set up from Fat Clients. However – I don’t have to constantly re-install hard drives – which used to be a nightmare (even with Ghost (‘Doze))!

The obvious downside is that, when the Server does freeze up or go down, we are really stuck! There is nothing ALL the kids can do – things get a bit rough! With Fat Client this wouldn’t necessarily happen. Another downside is that – even though we have such a powerful server and virtually all our clients are new P4 2.6GHz machines with 512M RAM – if we load, eg. Open Office Write it takes a good while for them all to load their programs – even though we have a 1000MHz ethernet link to the switches and 10/100′s to the clients. (Any comments would be valued).

Just an observation: The P1 and P2 machines definitely are not as fast as the P3′s and P4′s. (Unless it is my imagination).

- keith

Reply
billtodd

Interesting: you actually have fat clients in terms of their hardware (512 MB of RAM, a reasonably potent processor, and a Gigabit Ethernet link) – you’re just using them as thin clients in terms of configuration.

Why not change nothing but the client software and use them as *real* fat clients, with shared storage rather than shared application servers? They could still be diskless, CD/DVD-less, and floppyless, maintenance could still be limited to (file) server backups, and you’d still be able to manipulate the kids’ data directly – and I don’t understand where the ‘massive, massive’ software costs that you say you eliminated came from (unless you’re mistakenly chalking up money you saved migrating from Windows to Linux as being due to migrating to a thin-client configuration).

- bill

Reply
maddognh

LBX has basically been deprecated due to changes in the protocol over time.

Keith Packard gave a talk which described the issues:

http://keithp.com/~keithp/talks/usenix2003/

and today tunneling the X protocol over ssh with compression generally gives you better performance than LBX.

maddog

Reply
maddognh

Thin client environments are not for everyone, and there are often environments where thin clients should be mixed with “FAT” clients.

However, particularly in very large installations (call centers, banks, hospitals, etc.) or in remote installations that have good networking connectivity between the client and the server, thin client computing can make a lot of sense. We set up a kiosk in a library as a thin client. Despite the best tries of the library’s younger patrons to corrupt our system, if it does
hang at all, a simple reboot fixes everything. We have never had to visit the library….ever.

In addition, if you are doing true thin-client computing (only a web browser and perhaps a VoIP client), the CPU power and memory requirements that you need will come nowhere near what you need for a FAT client at the desk, and can therefore be satisfied by a much lower-power (3-5 watt) system instead of the 100-300 watt (or more) FAT client system. Multiply this times 3000 seats in a call center, and you now start to talk about real electricity savings, and real air-conditioning savings, as well as systems that have no fan, no disk, no moving parts, no noise. How long does your radio last versus your computer? Put a disk or fan into it and see how long it lasts.

Speaking of fans, hospitals are now realizing that the number one germ breeding area is inside a PC. Germs get into a nice warm environment, breed, then get blown out into the hospital by the fan. A lot of hospitals are now switching to fanless thin clients at nurses and doctors stations, with membrane keyboards that can be wiped clean with antiseptic.

As I said, thin clients are not the answer for everyone, but they have a lot of good points in a lot of areas.

maddog

Reply
billtodd

I’m curious about exactly why you believe that using a fat client in your library kiosk would have required any more management than your thin client did (rather than just requiring the same occasional reboot).

Some of what you’ve said suggests that you just haven’t been listening: when individual client loads are small, you can use a fat client that has *essentially the same hardware* (a comparable CPU, negligible additional RAM, no disk, etc.) that the thin client you describe does – and save the server resources that would otherwise be devoted to running the application at the server rather than at the client. In the example that you provide the additional CPU load and RAM impact of running the Web browser locally is negligible compared to the requirements of running the local operating system supporting the thin client.

I.e., whether at client is ‘fat’ or ‘thin’ is not (as least in the examples you have offered) a matter of *what* local hardware it requires, but of *how* it uses that hardware: if it uses it just for display management and communication, it’s ‘thin’; if it also uses it to run applications, it’s ‘fat’.

Or, to look at it another way, the incremental resources at the client required to run applications there cost very little (because they still fall well within the range of commodity products), whereas incremental resources at the server – and the application server itself, when compared with a simple file server – cost relatively a lot, don’t scale as well, and couple client loads together in a sometimes annoying manner.

Or to put it a third way, anywhere you’re *still* tempted to use a thin client for reasons of extreme economy you should instead be considering a dumb terminal – which requires even fewer server resources (green-screen form management loads are very low), costs less, and uses less power than a thin client does.

“Thin clients” aren’t exactly a new idea, you know: they were called “intelligent terminals” last time around, back in the ’70s. And they actually had some reason for existence back then, because they helped very expensive (and by today’s standards woefully under-powered) central computers scale up by off-loading a lot of their display management (which otherwise could bring the central computer to its knees when enough terminals were connected).

But PCs allowed both vastly more sophisticated display management and enough *local* computing power to handle most common applications as well (at least after 32-bit processors and operating systems arrived: earlier, PCs were used more as commodity-priced cost-effective replacements for the ‘intelligent terminals’ that had preceded them – or in cases where a user needed both a personal computer and a dumb terminal on the desk).

And after that PCs were increasingly used as intelligent terminals only to support legacy configurations that required such or when centralizing some processing activity actually made enough sense to be worth the effort (e.g., with a central, shared database server) – because it otherwise made sense to leverage that local processing power to distribute the processing load and decouple users from each other’s resource consumption.

Unfortunately, all this local autonomy created headaches for IT administrators, and their initial reaction was understandably to press for a return to centralized computing – a suggestion which the newly-liberated users resisted with equally understandable vigor. This struggle has see-sawed back and forth ever since, with the admins advocating thinly-veiled returns to yesteryear like thin clients and the creation of entire industries dedicated to the development of (complex) mechanisms by which admins can manage distributed autonomous PCs.

As I’ve been suggesting, all that’s really required to reconcile the situation is central (and centrally-manageable) storage. The network bandwidth is available: I helped design a diskless fat client network 25 years ago that used multi-drop 10 Mbit Ethernet fairly effectively, and Fast Ethernet’s point-to-point 100 Mbit/sec is more than adequate for any client activity short of streaming very-high-bandwidth data in bulk or heavily-parallel random access to many-disk arrays. But local storage is so in-grained in the PC mind-set (and in the Windows operating system) that such an otherwise obvious solution has yet to become the norm.

It’s nice that you’ve had good experiences using thin clients – just don’t kid yourselves that they also represented the most cost-effective use of hardware and management effort (license costs for proprietary software are of course a different story: a vendor can set prices fairly arbitrarily for different configurations to maximize profit, since proprietary software tends to behave a lot less like a commodity in this regard).

- bill

Reply
vegastech

A couple years back I rolled out a thin client solution for the billing department of a medical provider. Granted the back end was a Windows server but it was a great success.

In our case we used some Neoware (now HP) clients. We did have a lot of old proprietary HP 120Mhz machines sitting around that we could have used but decided on new equipment. Some of the reason were we didn’t want to support 5-8 yr old fat clients. For the old computers still being used fans, hard drives, power supplies, and the occasional mobo would die. We would scavenge parts where we could but the whole point was to move away from senseless jobs. A mini form factor that ran cool with no moving parts was a great move. We mounted the box on the underside of desks as well as set them on desktops. The clients and managers were happy to see such a small footprint. It may not be an important thing to a techie but the solution was for the client not for us. We also reduced the need for some licenses, a single TS server’a antivirus covered the terminal servers, while we still needed TS cals for Windows (argh) we did not need a desktop OS cal (they ran Linux w/RDP). Maintenance was non-existence, group policies locked the user’s desktop, all-in-all a great solution.

About the only thing I agree with on Bill’s post is the need to centralize data. That should be part of any fat or thin roll out.

These days I still roll out thin client solutions. On average I can replace 30-50% of desktops in new build-outs. It does depend on your environment though – I support mainly medical offices. And there are times where it is a complete crime to try to force a thin solution.

Rich.

Reply
billtodd

You don’t seem to have been paying very close attention either, so I’ll give this one more shot:

1. “A mini form factor that ran cool with no moving parts was a great move” – but could equally well have supported a fat client if the workload were nearly as light as the ones previously being discussed here (which it sounds like it was; if not, then you were tolerating increased overall system cost – due to the need for a very hefty server to handle the application load – to satisfy the client desire for a minimal desktop footprint).

2. “We also reduced the need for some licenses” – which is precisely what the final comment in the post to which you were responding observed: unlike the cases previously under discussion, when you throw commercial licensing into the mix anything can happen (but that has nothing to do with underlying resource optimization: it’s a commercial rather than a technical effect).

3. “Maintenance was non-existence” (sic) – just as it would have been using diskless fat clients.

4. “group policies locked the user’s desktop” – now we’re getting into Windows-specific areas (which were not part of the preceding discussion about Linux-based servers, but are still interesting when discussing the merits of the two approaches). As I already observed, Windows is not as readily suited to distributing fat clients as Linux is, so while it’s possible to configure Windows diskless fat clients locked down by policies established at their (suitably protected) server-resident system data it 1) is more difficult and 2) requires individual client Windows licenses. So in the case where Windows applications must be run on a Windows server (unlike the cases previously under discussion) there’s considerably more reason to consider thin clients (which is exactly what I observed at the end of my first post here).

- bill

Reply
pogson

Wow! I missed these fireworks that came during my relocation.

There seem to be two solitudes here: those who like thin clients and those who like thick clients. Is it like cat-people and dog-people? It seems there is no communication between the two. Perhaps it would help to supply some critical numbers. Unless you can describe what you are talking about in numbers, your knowledge is weak (paraphrasing Lord Kelvin).

I built a system last year: 153 seats – 96 thin clients – 57 multi-seat X thick clients. I used a gigabit/s backbone and gigabit/s to the multi-seat clients. I used six custom-built servers, one file/LDAP/http/NFS and the others were terminal servers. We saved at least $30K on licences using GNU/Linux. I saved nothing on the thin clients because I could afford double the number of seats because I was using GNU/Linux. $30000/$300 = 100 seats. Because I actually had a larger budget we were able to afford all kind of extra printers/scanners/cameras to make the whole system more useful. My hardware cost, per seat was about $300 including servers, not including cabling. Thick client would have been about $100 more for a drive and a larger case. The capital cost savings from using GNU/Linux and thin clients are both real.

Now, the killer numbers. On top of the low capital cost, this system has run two years with very little downtime and no full-time tech support. It runs on its own and one guy spends a few minutes a day checking on it or fixing anything that pops up. In two years, two memory modules and one hard drive failed. The users love it. It is faster than a thick client with local drive because there is no seeking when a cached file comes out of RAM on the server, there is no spin up time on booting, and the shared memory of GNU/Linux allows so many more processes to run in the same RAM. In two years, I doubt any of the servers was over 50% utilization. In fact, the whole system could run with 3 servers quite nicely. The cost per-seat for server was about $50. Now that would be about $30.

This year, I was working in a smaller outfit. I had a single server and 24 thin clients. Side-by side tests of a P4 thick client and identical hardware as a thin client was illuminating: OpenOffice took 7s to start on the thick client but only 2s to start on an old Xeon terminal server viewed on a P4 thin client. I could measure loads/bandwidth/memory utilization on every machine over SSH. The server used all its RAM, 50% of CPU, and all of its network bandwidth (100 mbits/s) with 24 users. I bonded in a second network interface and the network then had breathing room. No bottleneck. Everyone getting snappy service. Look at a thick client. It is idling except when loading programmes. With a terminal server, most of that work gets done by the first user and the rest used cached files. Thin client is just a great way to run as long as you are not doing full screen video or something that plugs a bottleneck. Ordinary browsing/word-processing averages out very nicely with small bursts between long periods of inactivity (human latency).

The most fun I had all year was to do the side by side comparison among P4 as a thin client, P4 as a thick client, and AMD64 X2 2gB as a thick client running Vista. Vista could not even see the first turn for all the dust the others threw in her face. 2 minutes to boot instead of 22s on the thin client. Several varieties of users tried this array of machines. No one liked Vista. Most were happy with XP on the thick client. All agreed that GNU/Linux on the thin client was the fastest by a large margin. There is just no reason to fill every seat with a thick client when a thin client will do very well or better. We even could do full-screen video on several thin clients at once but why bother when we could look up at a projection screen?

It makes sense to have a few thick clients in the system but certainly not in the majority of seats. They are too expensive to buy, install, maintain and they wear out too fast. A fanless thin client should be good for ten years or until its video resolution is obsolete. Last time I checked, 1024X768 was still very popular and it has been around for 15 years or more. A new thin client usually is OK for 1280.

Reply
twofoot

Bill, you seem to be rather full of yourself. Why not try a friendlier approach?

Reply
lelnet

Every tech article, here and everywhere else in the world, ought to come with a disclaimer: “If this technology we’re writing about doesn’t offer any meaningful leverage against the problems you face, just go ahead and ignore it…you are not part of the target audience for this article and should probably just go read the next one”.

For some N number of applications, thin clients make sense. As long as N>0, spending one’s time writing flames in the comment thread of a series about configuring thin clients makes _no_ sense.

Reply
billtodd

Wow – seems as if people just continued to drone on about how well their thin-client approaches had worked while *still* missing the point that for the kinds of Linux deployments under discussion the real test is not diskless-thin-client vs. fat-client-with-disk but rather using the *same* (thin-client-style if you wish) client hardware and varying only how it’s used (thin client vs. fat client software) while centralizing the storage.

Perhaps I should have kept paying attention, but since no one picked up on the above point after at least three previous iterations it seems unlikely that a fourth would have made any difference.

- bill

Reply
mrpurple

Bill seems to have some interesting ideas. I’d love to see his diskless-fat-client how-to. Sounds like just the answer for a lot of people.
Perhaps he could post a link.

- Richard

Reply

Hi there! Would you mind if I share your blog with my zynga group? There’s a lot of folks that I think would really appreciate your content. Please let me know. Many thanks

Reply

I will right away take hold of your rss feed as I can’t find your email subscription hyperlink or newsletter service. Do you’ve any? Kindly allow me understand so that I may just subscribe. Thanks.

Reply

Magnificent goods from you, man. I have understand your stuff previous to and you’re just too magnificent. I actually like what you’ve acquired here, really like what you are stating and the way in which you say it. You make it enjoyable and you still take care of to keep it smart. I cant wait to read much more from you. This is really a wonderful web site.

Reply

I աas suggwsted this web site Ƅy way
of mmy cousin. Ⅰ’m now not possitive
աhether thіѕ pjblish іѕ written throug Һim
аѕ noƄody еlse кnoա ѕuch certain аpproximately mу рroblem.
Υοu’rе wonderful! Τhank ʏοu!

Ꮮоօk іnto mmy web-site – Bar Equipment

Reply

I was extremely pleased to uncover th?s p?g?.
I ne?d to to t?ank yo? for y?ur time for t??s pa?ticularly fantastic read!!

I d?finitely real?? liked every litt?e
b?t of it and i als? ha?e you saved to fav tto ssee ne? th?ngs in your website.

M? website … pub table stools

Reply

Hi there, just beϲame alert tօ уοur blog through Google, аnd found
thɑt it іѕ гeally informative.
I am goimg tߋ watch οut fߋr brussels.
I’ll ƅᥱ grateful іf үօu
continue tɦіѕ іn future.
Lots οf people ᴡill Ье benefited from
ʏоur writing. Cheers!

Ⲏere іѕ mү website ::
square pub tables

Reply

?oes y?ur website ?ave ? contact page? ?’m
?aving ? tough t?me locating ?t b?t, I’d ?ike tto shoot you an email.
I’ve got ?ome suggestions foor ?our blog ?ou
might be intere?ted in hearing. E?ther way, g?eat blopg ?nd ? l?ok forward t?
seeing it expand ovrr time.

Look ?t my wweb site: replacement bike lock keys

Reply

It’ѕ gⲟing tо bе еnd oof mine ԁay, еxcept ƅefore finish I
am readin tһіѕ wonderful article tо
impropve mү кnoա-how.

Visit mʏ blog :: Bar Equipment

Reply

Hey! Do you kno? if they m?ke aany pluginns to safeguard against hackers?
g i joe renegades cancelled‘m kinda paranoid ?bout losing e?erything I’ve wor?ed hard on. Any tips?

Reply

Greɑt web site you haѵe hегᥱ..
Ӏt’ѕ difficult tօ find quality writing like уours
these Ԁays. І гeally аppreciate individuals like ʏⲟu!
Τake care!!

Ⅿy blog … Bar Equipment

Reply

Toda?, I went to the beach f?ont with my children.
? found a sea shell and g??? ?t to my 4 year old daughter and said “You can hear the ocean if you put this to your ear.” Sh? placed
the shel to her ear and screamed. T?ere wa? ? hermit crab ?nside and it pinched her ear.
Sh? never w?nts t?? go b?ck! LoL I kno? thuis is
complet?ly off topijc but ? had t? t?ll someone!

Here ?s my blog post Bar Equipment For Sale

Reply

Nice post. I w?s checking contiinuously thi? weblog and I
am inspired! ?ery useful information specially the ultimate section :) I ake
care of such informati?n much. I wass ?ooking fo? t??s partic?lar ?nformation f?r ? ?ong tim?.
Thank you and best of luck.

Als? visit my web page … king size mattress frames

Reply

Thanks foor eery other informative blog.
?he?? else couuld ? am getting that knd ?f informat?on written in s?ch a
perfect me?ns? I have ? undertaking th?t I’m simply no? running on, and I’ve been on the glance out for suc? info.

Also visit my webpage; canon g50 review

Reply

T?is article is tr?ly ? pleasant one it aesists neww net visitors, wh?
are wishing inn favor ?f blogging.

Feel free t? visit myy website … Bar Equipment For Sale

Reply

wondeful ?ut up, v?ry informative. ? ponder wwhy the other experts ?f th?? sector ?on’t understand thi?.
Yo? should continue your writing. I’m confident, ?ou ?ave ?
hu?e readers’ base ?lready!

m? webpage: end tables bedroom

Reply

Hey there! T?i? i? m? first visit t? you? blog! We arre a collection of volunteers and starting ? new
initiative in ? community iin t?e saje niche. ?ou? blog
pr?vided ?s beneficial information too w?rk on. ?o? havfe ?one a outstanding job!

Also visit m? ?age … resurrection

Reply

I d?n’t e?en understand how I stopped ?p r?ght ?ere, however I assumed thi?
post used to be good. ? don’t realize who you ?re ho?eve? ce?tainly ?ou’r?
?oing t? a w?ll-?nown blogger ?n cas? you ?re not a?ready.

Cheers!

Stopp bby m? h?mepage coach key chain fob

Reply

I use? to bee abgle to find ?ood advice
f?om your blog posts.

Feel freee t? visit my web ?age – luna bars minis

Reply

I’m really loving the theme/design ?f yo?r site. Do you ?ve? run into
any browser compatibility issues? ? few of myy blog audience
have complained ?bout my site not operating correctrly
iin Explorer ?ut l?oks great inn Chrome. Do ?ou h?ve any recommendations to ?elp f?x t?is problem?

??ok at my blog; lacoste black polo shirt uk

Reply

Hmm it ?ooks ?ike y?ur blog ate m? first c?mment (it was super ?ong) so I guess I’ll j?st sum itt up
what ? wrote and ?ay, I’m thorou?hly enjoying yo?r blog.
I t?o am an aspiring blog writer ?ut I’m ?t?ll new t? e?erything.
Do you h??e any suggestions f?r inexperiienced blog writers?
I’? genuinely appresciate ?t.

my homspage … rate remortgage

Reply

You ?re sso ?nteresting! I do not suppose I’ve rea? a single thing loke
that ?efore. S? wonderful t?o f?nd som?one with some unique thoughts
onn this topic. S?riously.. t?anks f?r starting this up.
This site is someth?ng t??t is needed on the web,
someone with a b?t of originality!

Feel free t? visit m? webb site tiffany lámpara

Reply

I know this if off topic but I’m looking into starting m? ?wn weblog and was wondering w?at all is requijred to gett s?t ?p?
I’m assuming ha?ing a blig lke ?ours wou?d coost a pdetty
penny? ?’m not ?ery web smart so ?’m not 100%
certa?n. Any tips ?r advice wo?ld be ?reatly appreciated.
?hanks

?lso visit my blog post … navy atomic clock online

Reply

Great weblog here! ?lso you? web sige ? lot u? fa?t!
Whatt host ar? yyou us?ng? Can I am gettung your affiliate hyperlink f?r you? host?
I wan my site loaded ?p ?s f?st as yo?rs lol

He?e ?? my web log … bear paw abigail sheepskin boots

Reply

?h?t’s ?aking place i amm new to this, I stumbled upon this I’v? discovered It positively
helpful ?nd it haas aided me out loads. I hope t? contribute & assist ?ther customers ?ike its helped me.

G?eat job.

Feel free t? surf to mmy blog post family guy voices characters

Reply

Hello I aam so glad I found yo?r blog, I re?lly fo?nd y?u ?y mistake,
?hile I was searching on Digg for something else, Anyways I ?m ere now and would ?ust
li?e to say kudos for a incredible post
?nd a ?ll ?ound entertaining blog (? a?s? ove the theme/design), I don’t hav? time to read ?t ?ll at the minute ?ut
? h??e saved it aand also included ?our RSS feeds,
so wh?n ? have t?m? ? w?ll be back t? read more, Please ?o keep ?p the excellent
wo?k.

?ave a loo? att myy website – end tables

Reply

Thankfulness to m? fathe who stated t? m? ?n the topic ?ff
this web site, t?is blg is really amazing.

my web blog americanexpress co

Reply

I’m really impressed with you? writing skills as smartly ?s ?ith t?e structure fo? your weblog.
Is this a paid theme or d?d you modify it ?ourself?
?ither way k?ep u? thee nice hugh quality
writing, ?t i? uncommon to peer a nice weblog ?ike this one nowadays..

Feel free t? visit m? h?mepage :: boys in boxer briefs imgsrc

Reply

M? brother recommended ? might l?ke thi? weeb site.
He was totally ?ight. ?his post actualky m??e mmy day.

You cann’t imagine ju?t hhow mu?? time I ?ad spent f?r thyis info!

?hanks!

Here is my website antique bar table

Reply

I’m real?y impressed w?th ??ur writing skills ?s w?ll as wit?
the layout on your weblog. Is t?is ? paid theme oor ?id you modify it ?ourself?
Any?ay ke?p uup t?e nicce quality writing, it’s
rare to se? ? nice blog like this one t?ese day?.

Feel frree to visit my weblog; motorized scooters for adults

Reply

Th?s piece of writing ?ill hslp t?e internet ?sers for building uup ne? blog or
?v?n a weblog from start to end.

Review my site counter height table

Reply

It is a?propriate t?m? to ma?e ? few
plans f?r thee future and it ?s t?me to be happ?.

I’ve r?ad this p?t up aand iif ? m?y ? desire to counsel ??u
few int?resting issues oor suggestions. ?aybe youu
c?n writ? subsequent articles ?egarding this article.
? desire to learn evben m?re things about it!

Ta?? a l?o? ?t my blo post: Air Rifles

Reply

What’? Happening ? am new to th?s, I stumbled ?pon t??s I’ve found It ab?olutely helpful ?nd itt
h?s helped m? out loads. I ?m hoping to contribute & assist
other customers like its aided me. Go?d
job.

Feel free t? surf to m? homepsge – white pub tables

Reply

It’s g?ing tto b? ending of m?ne ?ay, except ?efore end?ng I am readin t?i? enormous
article to imprdove m? knowledge.

Also visit my homepoage :: Bar Equipment For Sale

Reply

Veryy shortly t?is web p?ge wi?l b? famous amid al? blogging and site-building us?rs, ddue
to? ?t’s nice articles o? reviews

Here is m? site – rock paper scissors in spanish

Reply

Super blog ??u ha?e here but I was curious ab?ut if
?ou knew oof ?ny discussion boards t?at cover the sam? topics di?cussed h?re?
I’d rea?ly love t? be a part of grou? w?ere Ican ?et opinions
f?om ?ther experienced people th?t share th? same interest.
?f ?ou have any recommendations, plsase ?et m? know.
Thank ??u!

?lso visit m? ?omepage :: grain auger

Reply

Fantastic beat ! ? wluld li?e to? apprentice whilst ?o? amend y?ur site,
?ow could i subscribe f?r a blog website? ?he account
helped me a applicable deal. I have ?een tiny ?it
familiar ?f this you? broadcast pr?vided shihy transparent idea

my web ?age -sofa set

Reply

? am no ?onger ?ure where yo? are getting your inform?tion, ?ut
gre?t topic. I ust spend some time finding ?ut more ?r figuring outt mo?e.
Th?nk ?ou ffor gre?t information I used to be
searching for t?is info fo? my mission.

my web pagfe … post hole auger

Reply

It’? an amazinjg article in support ?f all t?? web ?sers; thy will tazke benefit from it I amm su??.

My wweb ?age gas powered post hole digger menards

Reply

I read this article ?ompletely regar?ing t?e resemblance ?f
lateszt and preceding technologies, ?t’s awesome article.

My blkg post … Air Rifle Equipment

Reply

Wonderfful bbeat ! I w?uld ?ike to apprentice ?hile
yo? amend yourr website, ?ow caan i subscribe for a weblog web site?
?h? acount aided mme ? acceptsble deal.
? ha? b?en a little ?it fakiliar ?f t?is
your broadcast ?rovided brilliant clear idea

Feel free to surf t? my pa?e belltec post hole digger specs

Reply

Write mo?e, thats a?l ? ?ave to say. Literally, it
seemks as though y?u relied ?n tthe video to make ??ur ?oint.
You definitely know ?h?t y?ure talking about, whyy throw ?way your intelligence on just posting videos
t? your weblog when y?u co?ld be giving us something informative t??
r?ad?

Feel free to surf to mmy site – earth augers

Reply

Magnificent ?oods f?om yo?, m?n. ? h??? understand your stuff
?revious to and you’?e just extremely excellent.
? really like whst y?u have acquired he?e, ?eally ?ike wyat yo?’re stating ?nd th? w?y ?n which ?ou say it.
You m?ke ?t etertaining and youu stil? care fo? to ?eep ?t smart.

? ?an’t wait to ?ead far mor? from you. This is
reall? a tremendous website.

?oo? ino my page – little beaver earth drills prices

Reply

I am not sue w?ere y?u’r? getting you? ?nformation, ?ut
?reat topic. ? ne?ds to spewnd ssome tim? learning more or understanding mo?e.
Thanks f?r excellent info I ?as l?oking for this info f?r my mission.

?ake a look at my homepage secte augerans

Reply

I mu?t th?nk you for the efforts yo?’ve put in writing tis
website. I aam hoping to ?ee the same h?gh-grade blog posts f?om you ?ater on as ?ell.
?n truth, yo?r creatrive writing abilities haas motivated
m? to g?t my o?n website now ;)

Al?o visit myy site: fence post auger rentals putnam ct

Reply

? havve been exploring for a litt?e f?r ?ny ?igh quality
articles ?r blog posts ?n thiis sort of space . Exploring ?n Yahoo ? ultimately stumbled upon th?s website.
Studying t?is informati?n So i am satisfied too convey that I’ve a very excellent uncanny feeling ? discovered exactyly ?hat I ne?ded.

I so much ?ithout a doubt ?ill mak? sur? tto don?t forget this site and ?rovides it a glance ?n a continuing basis.

My blog post ice auger

Reply

Hello there, ? do believe your site m?ght be h?ving web browser compatibility issues.
?hen I lokok ?t yo?r weeb site ?n Safari, it looks fine howev?r, ?hen opening in Internet Explorer, ?t ha? some overlapping
issues. I jut ?anted tto g??? you a quick heads up!
Ap?rt from t?at, wonderful website!

Check ?ut m? homepa?e: power augers

Reply

Excellent items f?om yo?, man. I have ?e aware y?ur stuff p?evious t? and ?ou’re just too magnificent.

? rea?ly l?ke what ?ou hav? acquired ri?ht here, ?eally like what ?ou
are stating and the ?ay in which you s?? it. You’re ma?ing
it entertaining and you continue t? take care
of too stay ?t smart. ? ??n’t wait to learn far m?re from
you. That is reall? a wonderful web site.

m? web p?ge: fence post auger

Reply

After I iniitially ?eft ? comment ? seem to
have clicked on the -Notify m? w?en new comments
are ?dded- checkbox ?nd fr?m now on e?ery time ? comment ?s added ? reccieve f?ur emails ?ith the same comment.
P?rhaps there is an easy method ?ou can remove me from t?at service?
Th?nks!

My homepag? post hole shovel

Reply

Amazing! It? ?eally awesome piece ?f writing,
I have got much clear idea concerning from this paragraph.

Feel free t? viisit my web blog :: ebay tractor post hole diggers for sale

Reply

I enjoy l?oking th?ough ? post th?t ?ill make men and women think.Also, thank you for allowing foor me to comment!

Her? is mmy website … earth drill

Reply

I was suggested this web site b? my cousin. ?’m nott sure whetuer th?s post is wr?tten by him as nob?dy elsse kno? such detailed ab?ut m? trouble.
You’re amazing! Th?nks!

?top b? my web site: antique barn beam drill auger

Reply

Gene?ally I ?o not learn article ?n blogs, howe?er
I w?sh to ?ay t?at t?i? wr?te-?p very compelled m? to try annd do so!
Yo?r writing taste has been surprised me. Thank you,quite great post.

Have a ?ook at my webpage – gas powered auger

Reply

Yo? actua?ly mzke it app??r r?ally easy
?ith y?ur ppresentation ?owever I t? find th?s topic to bee ?eally ?omething that I be?ieve
I w?uld ?y noo means understand. ?t sort of feels t?o complex andd extremely wide
f?r m?. I am loo?ing ahead on your ne?t post, I’ll
attempt t? get tthe cling of it!

My blog post: auger

Reply

Wow, th?? post iis pleasant, m? sisger is analyzing the?e kinds of things, ther?fore I aam go?ng to let know her.

L?ok at my weblog: echo earth auger parts

Reply

?eep th?s ?oing please, great job!

Sttop ?y my website grain auger spout extension

Reply

Hel?o there, just became alerdt t? your blog throug? Google,
aand found t?at it’s rea?ly informative. I am gonna watch ?ut for brussels.

I w?ll appre?iate if you conyinue this in future.
Numerous people ?ill b? benefited frokm ?our writing.
Cheers!

Feel free t? suef t? my blog post hole auger

Reply

Hey ther?! I know t??s ?s kinda off topic ?owever , I’d figured I’d a?k.
Wou?d yo? be ?nterested ?n trading ?inks ?r maybe guest authoring ? blogg article ?r vice-versa?
?? webskte ?oes ov?r a ?ot ?f the same
subjects aas ?ours and I feel wee ?ould gr?atly benefit from ?ach other.
If y?u’re inte?ested feel free to shoot m? aan e-mail.
I loo? forward t? hearinmg from you! Terrific
blog by the w?y!

Here is my website: earth auger bit

Reply

? was recommended this weeb site by my cousin. I’m not ?ure whet?er th?s post iis writt?n by him a? no one el??
?now ?uch detailed ?bout m? difficulty. Y?u ar? wonderful!
T?anks!

?lso visit my blog; ice augers for sale in mn

Reply

Thi? post wi?l hel? the internet visitors for
setting up new weblog or even a weblog from start t? end.

Feel free t? surf to m? pa?e electronic dart board

Reply

It ?s actually ? ?reat andd helpful iece oof info.
? amm glad thwt ?o? simply shared this helpful inf?rmation with us.
Please kee? us up t? d?te like t?is. Thank you
f?r sharing.

Feel free t? visit m? website :: earth drill

Reply

Fantastic blog! Do you have any tips and hints for aspiring writers? I’m planning to start my own website soon but I’m a little lost on everything. Would you suggest starting with a free platform like WordPress or go for a paid option? There are so many choices out there that I’m completely overwhelmed .. Any tips? Thank you!

Reply

Pretty great post. I just stumbled upon your weblog and wanted to say that I’ve truly enjoyed browsing your weblog posts. After all I’ll be subscribing in your rss feed and I hope you write once more very soon!

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>