On 29 October 2005 20:14, Bob Sanders wrote: > Since I'm rambling now, guess I should do the rest of the memory > download...
Let me join you in rumbling. ;-) Before I start just a little background: I do quite some consulting for SchoolNet Namibia (http://www.schoolnet.na) which has hooked up about 250 schools all over the country. All of them (well, almost all - some externally sponsored ones run Windows) running linux thin clients connecting to a linux server running the South African linux distribution OpenLab (http://www.getopenlab.com) and LTSP. Typical server configuration: P4 2.8 GHz 2GB ram 2 x 80GB normal IDE harddrive Typical client: refurbished x86 box currently PII or PIII 32MB ram > > One of the big problems with Linux diskless is it really doesn't scale > well, it doesn't allow for clients to run multiple versions of the os, Why would you want to do that? > nor > for different arch types to co-exist off one server of a different arch > type. That's possible, of course. The boot prom on the NIC in the client can boot any kernel/X server under /tftpboot on the server. > > Additionally, a typical diskless setup exports /usr as a read only file > system (which by most definitions, it is supposed to be). A typical LTSP server doesn't export /usr at all. There is no need for it. The client runs a kernel and an X server. If you want local devices to work, it also needs to run some other small daemons. All *applications* run on the server. [ snip ] > Another not so well thought out diskless problem with Linux is all the > setups use one kernel under /tftpboot or, at least the Gentoo Diskless > guide uses /diskless, which makes it a bit movable, but then falls into > showing the path as - /diskless/xxx.xxx.xxx.xxx (an IP number) instead of > using the node name. The other problem, is they all assume only one kernel > vs. a kernel for each host. Not necessarily. The boot prom on the client's NIC decides what to load from under /tftpboot on the server. My experiences with LTSP so far show: With a server like mentioned at the begin and fast ethernet, up to 20 clients are working well if you don't allow too graphics-intensive apps like movie players or that type of games. For more clients (up to 40), you need more ram on the server and a Gb connection between the server and the switch (clients can remain on 100Mb ethernet, of course). For small businesses, I prefer a different solution that involved solid state clients that boot from non-volatile ram. In that case, the client is completely independent of the server. All they talk to each other is X. Cheers from the beginning southern African summer Uwe (It's starting to rain outside, and I am feeling *good*!) -- 95% of all programmers rate themselves among the top 5% of all software developers. - Linus Torvalds http://www.uwix.iway.na (last updated: 20.06.2004) -- gentoo-user@gentoo.org mailing list
