Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Ask Slashdot: Linux Diskless Clients? 80

Posted by Cliff from the beefy-servers-and-thin-boxen dept.
Graymalkin asks: "I was wondering if there is a Linux program (or many programs) that would let me have a single server on a LAN and then a bunch of diskless clients. I'd like to make the clients have a motherboard, memory, a processor, and a NIC and get all their info from the server. If possible I'd also like to have all the networked stuff loaded into the server's memory so there's as few disk read/writes as possible. Can I do this?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Linux Diskless Clients? More

Ask Slashdot: Linux Diskless Clients?

Comments Filter:

  • diskless clients (Score:1)

    by Anonymous Coward
    check http://www.solucorp.qc.ca/xterminals/

  • Linux Network Computers (Score:1)

    by Anonymous Coward
    Hi,

    I'm helping set up a network which currently has about 40 Linux-based network computers which boot from Flash ROM on the network card. They have no floppy nor hard disk. Here are a few suggestions:

    1. We use Etherboot (http://www.slug.org.au/etherboot) for our network boot ROM, using a 3c905b-txnm network card.
    2. Use a healthy amount of RAM to prevent swapping and encourage the client machine to cache as much of its filesystem as possible. We used 128MB. Be aware that even without a swap partition the machine still _can_ swap -- it will just drop pages in demand-paged executables and shared objects, and read them back from the executable when needed. You don't want this to happen on a 10mbps network :)
    3. The main filesystems that have to be unique for each machine are /dev and /var. We symbolic linked many config files from /etc into /var so that / could be mounted read-only. We symbolic linked /tmp to /var/tmp so that it too is unique.
    4. Depending on your email setup, you may want to share the server's /var/spool/mail read-write to all of the clients.
    5. We use KDE as the GUI. There are some quirks in KDE that we had to work around, mostly dealing with a user being logged in on more than one machine (some pid files had to be moved to directories in /tmp -- but watch out for security concerns!)
    6. Locking over NFS appears to be broken in Linux 2.2. Thus we couldn't use YP. Instead, we force password changes on the server and regularly cp the password file and shadow file to the exported /etc directory for the clients. That's a real kludge but it works.
    7. We used RedHat and had to modify rc.sysinit extensively and re-order much of the boot-time scripting. I've heard that other distributions like Slackware are much easier to set up for network computing than RedHat. It was quite a chore....
    8. In our setup, our mostly-10mbps switched network works just fine. We're using 100mbps capable cards in the event we rewire our building :) It takes about 75 seconds for a network computer to boot completely (KDE login screen with X running)
    9. Be sure to disable unneeded processes for the client systems! You probably won't need apache, samba, etc. on the clients....

    But -- once it is set up, network computing is very low-maintenance. And, adding new machines is just a matter of configuring the NIC, installing the boot ROM, and adding an entry for bootpd. We have a script that auto-creates the /dev and /var directories for a new network computer.
  • If you're using the client as not much more than a dumb terminal, you don't need much memory. It's possible to run a Linux machine in 8M of physical RAM and no swap at all... I've been doing it with a diskless 386-16 for quite a while now. If you want X, you'll need more RAM, of course, but for telnet/ssh, 8M is fine.
  • They have: http://www.siemens.de/pc/business/scovery/index.ht m
  • Does anyone know if it's possible for the diskless clients to have sound through X applications run at the server?

    The workstations will need a sound card, of course, but is X able to distribute the sound?
  • There's a huge difference between an X station and a diskless client. With a diskless workstation, the programs are still run locally -- so sound is no problem.

    --

  • I've heard that having a swap space makes linux run 10-20% faster, even if that space is never used.

    --

  • Diskless Linux clients have been possible for a few years now. There are two projects that enable you to do this Etherboot [slug.org.au] and Netboot [www.han.de]. Both groups have written Boot Prom images for many popular NICs and they ship additional tools that you need to set up diskless machines.

    The differences between the two projects include 1) size of the images, 2) number of supported NICs, and 3) available features. Nonetheless, they aim for compatibility between each other and it is often worthwhile trying both and finding out which one works better for your particular configuration. (As a co-author of Etherboot, I am somewhat biased).

    Rather than asking your questions on Slashdot [slashdot.org] you probably stand a better changes getting answers to your technical questions, if you subscribed to the combined mailing list [slug.org.au] for the two projects. There also is an archive [www.han.de] of all the messages ever posted on this list.

    Both Etherboot and Netboot allow to load the Boot Prom image from floppy disk while you are still testing your environment. Once everything works, you can decide to burn an EPROM and eliminate the need for the floppy disk. Of course, with modern NIC cards things are easier, because some of them already include a FlashPROM.

    Another very promising project is NILO [nilo.org]. It has originally been started by one of the Etherboot authors and it is currently being written from scratch under commercial sponsorship (the entire project will is GPL'd). See the home page for all the details.

    Eventually NILO will probably obsolete Etherboot and Netboot for everything but very special purposes. It currently is under active development and while we would appreciate more alpha testers it isn't really very useable for real-world applications. There will be announcements on Freshmeat [freshmeat.net] about the progress of this project.

  • check out the network block device included with the kernel. You can use it as swap for diskless machines.

    -paul.
  • There are BIOS'es that you can tell to boot off the net. If you get you're BIOS so far to boot off the net you'd simply use tftp protocol or bootp protocol to have a kernel loaded (typically residing in /tftpboot..)

    Indeed BTW diskless clients have often disks, for swap

  • Re:cd-rom clients (Score:3)

    by tgd ( 2822 ) on Monday June 21, 1999 @08:00AM (#1841991)
    I've done that too a half dozen times for servers.

    I burn the root system on a CD, boot from that. It mounts the CD as / (and /usr is sitting on /), /etc comes off a write-protected floppy disc, and everything else mounts from the drives in the system. Its a little slower to boot up, and a bit more of a pain to upgrade the core software, but at a buck a pop its nice to know that even in a worst-case scenario, I would be able to still use the system after a reboot. Upside was even a major problem on the system could usually be fixed with a reboot and restore from tape without having to get at the machine (they were colocated at the time...)

    So I'm sure it would work for workstations too. I ran across an overley filesystem a while back that I experimented with for embedded Linux applications, where a flash partition was mounted with the overlay filesystem, so files could still be "updated". Never got it working right, but I didn't spend a lot of time trying. Might be a good solution to a CD-Rom based install as well, I'm not sure if you can mount an overlay over NFS or another technique.
  • It is possible to have a large ramdisk, but the Linux kernel sets the maximum size to 4M, so you'll have to change the rd_size in /usr/src/linux/drivers/block/rc.c.

    I changed it to int rd_size = 131072; so I could have a 128M ramdisk.

    Then I added an /etc/rc.d/rc.ramdisk:

    # Install the ramdisk module.
    insmod rd
    # format the ramdisk
    dd if=/dev/zero of=/dev/ram0 bs=1k count=128k
    # Make an e2fs filesystem
    mke2fs -c -v -m0 /dev/ram0 131072
    # mount the filesystem
    mount /dev/ram0 /data/mysql/var/RD
    # Copy the data into the ramdisk
    cp -a /data/mysql/var/Archive/Archive.* /data/mysql/var/RD
    cp -a /data/mysql/var/Econ/Econ.* /data/mysql/var/RD
    chown -R mysql:db /data/mysql/var/RD

  • It'll work if you're more patient than Job. An eraser don't set you back too much. With a timer, it'll be worth every penny. Keep in mind that you can "cook" an EPROM if you expose it too much.

  • would it be possible to instead implement a dual cd-rw system, with a small ram disk? Where you can have the first cd-rw contain the file system, and if you need to make changes, you send it to the ram disk, and you have an automation program that does a sync on the second cd-rw every period (day/week, depends on your requirement)and then the system reboots it self, and switches over to the second cd-rw which was just burnt as the main filesystem. This could go on and on for a said period of useage. The only downside is that you will need two fast cd-rw drives, so that you can read from the cds at a fast rate. The only down side to this may be that you only have a limited number of writes on a cd-rw media until its no longer useable. so you will have to know that in advance, and schedule a maintance check on it. Also you will need some good error checking and redundancy, cause if you get a bad burn, your system may not come back up the next time.

    Sounds like a very fun project to work on...
  • I have a CNet (CN600Eplus) ethernet card, and a boot rom for it, but the rom apparently uses the RPL protocol. Anyone know where I can get a RPL daemon for Linux, or of a place that has some information on the RPL protocol?
  • Would it be practical to use diskless workstations as Beowulf cluster nodes? Say, dual P3-450's (or hacked Celerons), 256MB of RAM (128meg DIMMs are under $100 apiece!), 100Mbit Ethernet (dumb hubs are cheap), booting off floppy, and not much else. Would this work for raytracing, SETI@Home, decryption, and similar tasks? You could build dual P3 nodes for not much more than a grand, and dual Celeron nodes for substantially less. Abit's upcoming dual Socket 370 board would be perfect for this.
  • Diskless nodes is a path many take when they build Beowulf clusters -- makes it easier to replace nodes &/or expand the cluster.
    Christopher A. Bohn

  • Well, at my lab most of us use our PCs, Linux boxes, Macs etc chiefly as VNC [att.com] terminals to our real work running somewhere on the network....

    But we may be biased in that direction!

  • I eval'd a WYSE Winterm a while back. They do exactly what you want. They boot Slackware Linux off a NFS server. Each client is an x86 computer with no harddrive. They all share the same NFS tree on the server with client specific settings stored in the /etc directory under their MAC address.

    It was cool just to see how they did it. The machine itself was a bit slow, and I wanted a little more (better local browser, possibly NIS, graphical login?, etc). They have a new model out thats bigger faster better, but I haven't seen it yet.

  • Use esound...

    I think you can find esound info on www.gnome.org


    "There is no spoon" - Neo, The Matrix
    "SPOOOOOOOOON!" - The Tick, The Tick
  • http://www.csis.gvsu.edu/matt/projects/wopr/diskle ss.html
  • IMHO yer gonna need a local page & swap file, and I'd be inclined to load fonts locally as well.
  • Probably the first thing to go check is the assorted howto's about setting this up. Howto.linuxberg.com [linuxberg.com] is a good place to go. As far as specific hardware, look for network cards with the boot rom, or have a floppy drive and one disk to get things going on boot.

    -----
  • I don't think that the network cards that support boot proms are expensive. I got some NE2000 compatible PCI 10baseT cards that support PROMS for US$20. I'm not sure if it supports 32k though. The only expensive part would be the writer and eraser.
  • Just as a footnote, your setup used to be extremely common in the late-80s, early-90s with DOS-client LANs. Even when the clients had hard disks (which weren't cheap), applications were run off the network because it made administration simpler. There usually was a boot menu that launched from the Novell login scripts that insulated the users from the DOS prompt.

    What killed this setup was Windows 3.1. Usually swapping over the network was extremely slow, and all of your Windows clients had to have exactly the same hardware for it to work (at least for the stuff it handled like video and mouse). Windows also did not like it's system directory marked read-only.
    --
  • ...the cost savings of not buying a hard disk for each unit is negligible...

    Everything counts in large amounts. Plus, there's the administration problems and costs associated with all of those negligible units.
  • Instead of expensive network cards with boot proms, you could also get EPROM floppy emulator cards like this [backplane.com.au] or this [iosis.co.uk] and then copy a working boot floppy image onto it. You can find these and more by asking Alta Vista for: solid near state and emulate and floppy and EPROM
  • As the name implies, it is a networked machine which doesn't have to have its own hard disk (but may have one). All files it needs it gets via NFS (Network FileSystem). If it hasn't local hard disk, how does it boot? One solution is booting by ROM plugged in the network adapter card, but you must have enough knowledge and access to EPROM burner to do it. The solution I describe is booting by floppy disk which contains Linux kernel image. Once loaded, kernel takes over the control of the diskless client and floppy is not needed anymore.

    ...

    Because I'm tired of writing it all over again, I put it on http://acs.lavsa.com/sskracic/diskless/ [lavsa.com].

    This describes one real-world setup and also sheds some light on motivation. In my experience, deploying diskless (Linux) clients led to significant decrease in hardware and software cost, and (most important!) greatly reduced admin time.

  • Speaking of booting off of EPROM's, does anyone know if a flourescent style black-light puts out enough UV to erase an EPROM? I built a simple programmer, but I don't want to buy an eraser, but I do own a black-light. Any help would be appreciated.

  • This is already supported in the kernel. You just need to export the server filesystems with NFS, and set up the clients to boot with NFS as the root filesystem.

    What you want is basically to just set up the server with the software for the clients exported over NFS, and a bootable area for the clients. IE, you'll set up a directory tree on the server which will work as a root directory for your clients (with some separate writable space for each client). You'll then probably end up making a boot disk for your clients (easier than getting your NICs to use a boot rom), with a linux kernel on it set up for booting with NFS as the root directory.

    Except for the little trivialities, like:

    • Setting up the server side root dir for the clients properly
    • Setting up the NFS root kernel and the boot disks

    this is a complete no-brainer. Nothing to it.

    A few tips:

    • Read the NFSROOT howto. This would be a good place to start. Also, Documentation/nfsroot.txt in the kernel distro.
    • You're going to want to format the boot disks with some sort of filesystem and put lilo on them, and pass the nfsroot kernel command line through lilo.
    • You'll want kernel DHCP for the room full of machines, but start with static ip's.
    • Start off with your boot sequence simple. Use a statically linked ash or something as your init command, and just get the client to actually boot. Then worry about making it do something useful.
    • Remember that each client needs some writable space of its own to use during booting. For example, they need to write to mtab, so they can mount filesystems correctly, and /var would be a good idea for storing some PID's etc. They can all share /bin, /sbin, /usr, /lib, /dev, /opt etc. It would be a good idea to give them separate /tmp directories as well.

    A couple other things:

    • The disk access on the server isn't a problem. The most recently used files on the disk are automatically cached. If you really want more control, you could use ram disks, but it would probably be less efficient.
    • One thing you may be concerned about is that you can't currently set up a swap file for each client over NFS. This means you may have a problem with running out of ram on the client machines. (There may be a patch available for this, or you might be able to use some other network file system) You could put a hard disk in each one for swapping, but that would obviously defeat the purpose of running them over the network. Make sure the clients have sufficient ram for normal operation.
    • Performance may not be the greatest, that sort of thing.
    • Remember to compile the client kernel right. You know, don't build the things you need to boot, such as, say, the NIC drivers, as modules, because that wouldn't work too well.

  • If you have enough memory its not a problem. Enough memory depends on what you're going to run - if they're just basically going to be X terms, 64 should be heaps. They make very fast xterms. Even as workstations they will probably run ok, but you may need more memory.

    Fonts over the network is not really a problem either, either nfs or a font server is fine. I've had pools of terminals netbooting and running off a single UE2 server with few performance problems. I mean generally X11 applications dont use that many fonts anyway - and you're not likely to be running gimp are you? :)

    Of course, that may depend on what you consider reasonable performance :)

    The actual setup for net-booting linux isn't too hard either, there are HOWTO's or other doco on setting up bootroms and so forth to boot a kernel over the network.


    __// `Thinking is an exercise to which all too few brains
  • The FreeBSD Handbook (http://www.freebsd.org/handbook/diskless.html)
    has a quick guide to diskless operation.
    You can run netboot from an eprom or a diskette to bootstrap the kernel from the net too.
    We (http://www.ing.unipi.it) actually run Diskless FreeBSD with per host configuration.
    More info (not updated!) about our local setup: http://www.iet.unipi.it/~luigi/diskless981113/
    P.S. We run Debian GNU/Linux and RedHat too, no OS war intended.
  • Etherboot (prop. Ken Yap) is here [slug.org.au].


    Also have a look at Ken's presentation on this page [slug.org.au] for info on setting up a discless PC as a X terminal.

  • University of California Deptarment of Mathematics
    has 38 diskless workstations. Currently they all use a kernel disk which uses nfsroot to mount file systems off a central server. Basicly all of our Grad Students and Visiting Research Profs use them.

    Looking for a way to get bootroms for the Intel EEPro cards -- unfortunatly the first 18 systems we bought have the non-boot-prom-socketed NetGeat 310TXs so we can't use proms on those..

    This is basicly a home-brew setup, always looking for better ways to do it. One thing thats neet about this setup is that we export most of the filesystems read-only (had to hack some of the mount utils to keep from fiddling with files in /etc.)
  • Thank you for the very informative post! Have you tried this setup over a DSL VPN or any such link?

    Thanks!
    Eric
  • Thank you for the very informative post! Have you tried this setup over a DSL VPN or any such link?


    Thanks!

    Eric
  • Thank you for the very informative post! Have you tried this setup over a DSL VPN or any such link?
    Thanks!
    Eric
  • I used to work for a company that was doing diskless workstations. The purpose that we had was to make the world's cheapest X servers/Java clients. We needed zero administration, because we kept our customer base computer-illiterate.
  • If you dont like the kernel-on-a-floppy way, you
    could look up the netboot and etherboot projects
    (http://google.com will lead you there)

    / andesr
  • You can leave the kernel source alone and change
    one (1) line in the rc.ramdisk script, let:

    insmod rd

    become

    insmod rd rd_size=131072

    / andesr
  • I've been using software from Sun for about three years now called AutoClient, that allows not diskless workstations, but cached OS workstations.
    Most of the advice you've gotten saying not to go totally diskless is right; no matter how much memory a Unix system has, it really need a swap space and swapping over the network is unbearable.
    Autoclient uses a cached filesystem for root and usr, which means that when it queries the server for files, it stores them in a filesystem that only has structure while the system is runing. This does mean longer boot phases, but my systems are rarely down. It is much nicer for administration, since I can change all the workstation root directories with a foreach loop, and then execute a command to tell the clients to update their root directories. Also, I only have to apply patches to the server, and patches get applied to all the root directories of the clients. They all share a common /usr.
    I've been debating setting up something similar for Linux with a friend, though we'll probably try it with sparc systems first, since it's considerably easier to boot a sparc from the net than a pc.

    Bob Campbell

  • RTFM! (Score:2)

    by zmooc ( 33175 )
    Just read the Diskless-HOWTO [linux-howto.com]. It should come with your linux-distribution; usually it's located in /usr/doc. btw I have a bootrom-burner, so if you need a custom bootrom, just mail me.
  • Why is a swap file needed?

    At the moment RAM is so cheap that you can
    get 256MB of RAM for the price of fairly low
    end HD. I would have thought that with current systems, virtual memory is largely obsolete.

    Most people seem to be considering diskless
    systems as slow dumb terminals, but this doesn't
    need to be the case. Todays low end systems
    (Celeron or K6-2) cost very little and can
    act as extremely fast network computers.
    I've actually been considering building a
    dual PIII diskless system... ;)

    I've also seen for sale a diskless server,
    which gets it's data from a separate RAID
    array.
  • Last year Siemens had Linux-based NCs at their CeBIT booth. They were diskless, but had a 8 or 16 MB flash memory to boot into the web AFAIK. Maybe they have some info in the web.
  • Check out Gero's netboot pages [www.han.de] It features a complete system to boot any intel machine with bootp/tftp. If you don't have access to an eprom writer for your ethernet cards, it also works with a floppy. Allows you to network boot MS/DOS (also WinSucks9x) and of course Linux

  • Our school used to have Dell 486/25's set up as diskless clients, running Netware 3 and Windows 3.1. You logged into Netware from DOS, then it automatically loaded windows. The machines wouldn't boot if the network was down.

    This increased security no end, especially once they removed the floppy drives. Also PCs set up like this are less nickable.

    Anyway, I'm sure the hardware exists to do it.
  • I, too, have set up diskless clients, and love 'em. This guy is right on target (see original message)

    You don't even need to go PIII, either. A nice cheap little AMD K6-2 (or the new K7, I suppose) would probably do just find, for considerable less money. (I have a AMD K6-2 350 that, on a good day, keeps up with a dual Intel PII-233)
  • Not X itself, but i think KDE supports it using kaudioserver. However, I don't recommend running KDE in this situation because KDE likes to use LOTS of ram and it tends to cause X to bloat to obscene sizes.
  • To be honest, why use diskless workstations? No one will be able to do anything with them at all if the network or the applications server is down. Also, the cost savings of not buying a hard disk for each unit is negligible, and there are even programs out there that can store a drive image and then write it onto each workstation's hard drive at a specified interval if you're that worried about people crapping up the system with personal junk. All in all, you're better off going with real computers.

    I think so, at least.
  • Hi,

    we use a lot of diskless Linux clients here at several locations of our company and they work great.

    If you have a company environment with a central database and/or file server you depend on a central server anyway so it wont bother you if the clients dont work without the server.

    As for administration its the best thing to do. Its more like having ASCII terminals. You buy a new box, hook it on the network, make a few configuration entries on the server and as soon as you boot the new client it will have all the same software as the other clients, it will have an identical configuration and it will have access to all your personal files.

    And if you care for a good integrated network configuration (NIS, NFS, DNS, etc.) you can really say that as Sun puts it "the network is the computer". People would be able to log in from every workstation and have the same desktop and applications everywhere. No need for complex registry things, just a shared /home and /usr file system :-).

    Often people think a diskless client could be compared to X terminals or things like Microsoft Terminal Server, but this is not true! With a diskless clients each user has its own CPU and memory. They only share the disks. In times where every office application has animated cartoon characters talking to each other you need a lot of CPU power :-).

    Another misconception (in my belief) is, that a diskless client is a "thin client", meaning a cheap client. We use our diskless clients for Java and office applications. This cant be done with an old 486. This cant even be done with good performance with a JavaStation (at least the last one Ive seen). But it can be done with a Pentium III 500 Mhz. And theyre cheap enough (at least for serious company use and more so when you look at TCO). The main benefit with diskless clients is not saving the money for a disk drive, but easy system administration and less problems for the users!

    BTW, the performance is ok. Its a bit different from "normal" configurations. You might need to wait a little longer for the first load of a program after a reboot, but programs like Netscape or Applixware Office start in a couple of seconds and it will be faster the second time. After the initial loading you wont see any difference, at least if you dont have huge files as in image or audio processing.

    My recommendations for say 10 diskless clients with heavy workload would be (things may vary):

    Server:
    256 MB main memory (you cant have enough here)
    Pentium III 500 MHz (the current user-space NFS needs a lot of CPU Power)
    SCSI disks (with diskless clients parallelization is important)

    Clients:
    128 MB main memory (they shouldnt swap)
    Pentium III 500 MHz (could be less depending on your applications, we use Java)
    Floppy (we boot from a floppy)
    NIC (buy a good one with a stable driver, as every bit will go through here; we use DEC Tulip based PCI 10/100 NICs).

    Network:
    It might work ok with 10MBit, but you should really go for 100MBit.
    Buy a dual speed hub.

    Now to the Linux setup:

    First thing the client needs is a Linux kernel in his memory. You can use a boot PROM or start with a floppy which Id recommend. Just compile a kernel and dd it onto a floppy disk.

    The kernel should have drivers for your favorite NICs compiled in and it should have support for root file system on NFS and Bootp support. After building the kernel you have to use rdev to actually configure the root file system.

    After you start the kernel, it will ask a Bootp (DHCP) server for its IP address and root file system. This will then be mounted via NFS and the rest goes like any other Linux box.

    If you want a really integrated solution, you have to set up the following subsystems:

    * DNS Domain Name Server
    Have entries for the server and all clients. Better than /etc/hosts in the long range.

    * Mail
    Use the server as SMTP and POP3 server.

    * NIS/YP Network Information System
    Use NIS for a common login administration.

    * DHCP/Bootp
    Use DHCP for configuration of diskless clients.

    * Printer spooling
    This is a bit tricky with apsfilter, but having network printers or printserver helps.

    * NFS Network file system
    This is the base system for sharing files. You can share /home, /usr, /opt between server and clients and should have / and /var separate for each.

    For start make a copy of your Linux filesystem and name it say /clients/client1. Then compile a kernel with root NFS and setup DHCP or Bootp. With only a few changes on your server you should be able to boot a diskless client. The changes would be DHCP, an entry in /etc/hosts or DNS, and NFS server with exporting /clients/client1).

    I did this using a SuSE Linux 5.3 but it should work with every distribution (we still use this older version, because in a company environment you just cant change your OS every other day :-).

    Just try it out step after step: first boot the client and see if you get a Bootp request at the server. Then Bootp should give the client a new IP address. Both should be fairly easy. The tricky part might be getting a root file system from the NFS server. But then, you only have to get /etc/exports right. And then the client will boot and you can make adjustments in the root file system.

    Good luck and best wishes!

    Michael

    P.S.: I made my first Unix diskless client system about 10 years ago using DECstations running DECs Ultrix because our university had ordered several DECstations but only one disk because of a money shortage :-).

    I believe, that the ability to run on diskless clients is a huge advantage for Linux compared to Windows NT. As I said, the Microsoft Terminal Server is a different concept and its worse in performance because all users share a CPU.

    But on the other hand, if you push Linux so far and make heavy use of all daemons ranging from DHCP to LDAP, you will also see its limitations. Coming from different persons, different parts of the system might not work as good as possible with others. Examples include the integration of NIS. I mean, most things in Linux work, sort of, but it could be better. Does anybody know how RedHat scales in this area, as I never actually tried it.

    If you feel the need to criticize me for "Linux bashing" please make your own diskless client configuration first and install it in several companies with real users and real world problems and then come back. But to calm you: a large Linux installation is better than a large NT installation any day :-).
  • Checkout our website at www.dresults.com,
    we are selling network cards with bootroms,
    eprom burners, and complete workstations with
    the bootrom and everything. You can also purchase
    through Linux Systems Labs (www.lsl.com).
    If you run the applications on the host, and
    just run the Linux kernel, Xserver, lpd
    on the workstation, you don't even need to worry
    about swap.
    Also, we are using Net Audio Services (NAS) to handle sound.
  • we are running a 50 diskless linux stations for
    the undergraduate students (CS dept. Hebrew Univ.)

    this is our most reliable configuration for large numbers of workstations. app. servers supporting
    80+ NCD X-Terminals are far less stable.

    the author of the scripts for diskless station administration is planning to post them soon on the www.mosix.cs.huji.ac.il, so check there for
    updates
  • There is a company here in South Africa who has successfully done this for about 3000 workstations (AFAIK). They are called UCS [ucs.co.za]. I don't know how much they'll tell you, but it never hurts to ask...

Slashdot Top Deals

There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann

Close