After 2 Years of Development, LTSP 5.2 Is Out

The Linux Terminal Server Project has for years been simplifying the task of time-sharing a Linux system by means of X terminals (including repurposed low-end PCs). Now, stgraber writes "After almost two years or work and 994 commits later made by only 14 contributors, the LTSP team is proud to announce that the Linux Terminal Server Project released LTSP 5.2 on Wednesday the 17th of February. As the LTSP team wanted this release to be some kind of a reference point in LTSP's history, LDM (LTSP Display Manager) 2.1 and LTSPfs 0.6 were released on the same day. Packages for LTSP 5.2, LDM 2.1 and LTSPfs 0.6 are already in Ubuntu Lucid and a backport for Karmic is available. For other distributions, packages should be available very soon. And the upstream code is, as always, available on Launchpad."

Comments

Impressive...

[King InuYasha]

With 14 contributors, that they got it done in two years is impressive. Hopefully with this update, more distributions will be able to readily support LTSP 5.2 again...

Excellent news

[bloosh]

This is great news to hear. I've been using LTSP at a school for all teachers and students since 2003 with excellent results.

I don't see what the big deal is

[ipquickly]

I've been using ssh and X11 for 6 years now to do exactly what this project says it does.
I fail to see how this project improves things. Is it just simpler to to set up?

(Btw I'm writing this on an atom-thin client using a wireless connection to run Firefox on an old P4 server.)

Re:I don't see what the big deal is

[stgraber]

Yes, LTSP has been around for more than 10 years now and is really about making all that easier. It lets the user choose if he wants to connect to a Windows server using RDP or to a Linux box either using X11 over SSH or just using ssh for authentication and X11 clear on the network for better performance. The main addition is having a login manager for that which can call a lot of hooks, mount the home directory directly on the thin client and then mix local and remote applications.

Re:I don't see what the big deal is

[evilviper]

LTSP isn't some X11 extension. It's a distro that sets up a server, and supports a large number of diskless thin clients, with lots of features like running apps locally, accessing local disks, etc., etc.

Running X11 apps over SSH has NO RELATION TO WHAT LTSP DOES.

Re:I don't see what the big deal is

[drinkypoo]

LTSP isn't some X11 extension. It's a distro that sets up a server,

Sigh. LTSP is a system mostly utilizing existing servers that provides XDMCP over SSH, and the rest of your comment is true. But it's not a Linux distribution; it's software for Linux. And while it does have a lightweight login server, the really interesting parts are the ability to use local machine resources (as you say, disks and other USB devices) and that it sets up the netboot configuration[s] for you.

5.2 is a bugfix release for 5.199 and as compared to 5.0 most of the improvements are in speed and so-called 'fat client' support, where most apps are actually run on the client. There have also been tweaks to the way audio is handled.

Re:I don't see what the big deal is

[Antique Geekmeister]

VNC tends to be significantly faster than SSH+X11. It does present some security issues in normal use, but the concepts have been around for years.

Re:I don't see what the big deal is

[KermitTheFragger]

After I started using NX ( http://freenx.berlios.de/ and http://nomachine.com/ ) I never looked back at VNC. NX provides near local speeds for remote X11 desktops.

Re:I don't see what the big deal is

[micheas]

But do you have sound working? Can you plug in a usb drive on your client and see it on your desktop? Yes you can do all that, but you also need to manage it, and LTSP supports installations of as large as 30,000 desktop clients.

The point is to have a thin client work like a desktop.When it works it is a huge time saver for admins, as you have one server cluster to back up and maintain, and a bunch of diskless workstations that can be unplugged and replaced with no configuration or installation beyond maybe needing to put the mac address in dhcpd.conf

LTSP is probably more work than it's worth if you have less than five work stations, but more than five workstations, and the long term savings probably make it worth the initial time investment, as you need beefy servers and good redundancies, but after you have a high availability server cluster that people are logging into, management as become a lot easier.

Re:I don't see what the big deal is

[Daengbo]

You don't do exactly what the project says it does. The project uses diskless system with no ROM OS to boot to a full X session or RDP session. Jim McQuillan basically wrote a system to duplicte what he was doing for hospitals at the time. When I used LTSP often (from 0.9 to 4.0, circa 2000-2004), the process worked like this:

1. PXE boot to find a kernel
2. Get DHCP address
3. load the root file system
4. Pivot root into the new system
5. NFS mount /home
6. Start X session with optional server chooser.
7. Log in to an X session on the server while still being able to use local sound, printers, and USB drives.

I'd also like to give a big shout out to Eric Harrison, who made the whole system easy to use for schools with K12LTSP (now K12Linux).

Re:I don't see what the big deal is

[markdavis]

VNC on Linux/Unix (or any platform) is *HORRIBLY* slower than native X11... there is no comparison and the technologies are completely different. VNC is also tremendously more network and CPU load on both client AND host.

VNC just unintelligently pushes a bunch of screen bitmap updates on a huge graphic image. X11 is a true windowing/widget/primatives protocol that only draws what it needs and where it needs it and the Xserver does a lot of intelligent stuff. On a good network you can't tell that a program is not running native when remotely served through X (with the exception of motion video).

Don't get me wrong- VNC is extremely useful. And, in fact, we use it for "desktop sharing" to help support people running Xterminals, which, themselves, are running remote X (X clients running on a remote host and displaying on the local Xserver).

Re:I don't see what the big deal is

[Anonymous Coward]

Sigh. I get moderated off-topic for gasping. How sad.

Re:I don't see what the big deal is

[Anonymous Coward]

I'll just leave this here > http://www.x2go.org/

Re:I don't see what the big deal is

[multipartmixed]

You got any idea if you can run it effectively with those little Sun things? Geez, I forget what they're called, but you normally have to run special software on a sun server....

SunRays!

Any idea if LTSP supports SunRays?

It might be nice to buy a few and stick 'em around the house, have a central server in the garage somewhere.

Re:I don't see what the big deal is

[tommy_traceroute]

>LTSP is probably more work than it's worth if you have less than five work stations

Sorry, but I absolutely have to disagree with that statement. I have been using LTSP for the past four+ years to provide access to my family's 3 workstations. Even if it were only two machines, I would count my time well-spent, given the great reduction in maintenance and support time per user. Having everything centralized for updates and management pays off very quickly (in my experience), even for just a small user base.

p.s. - HUGE props to this team, they have done an incredible job. I had no idea it was such a small group of contributors. Many thanks from a very grateful user!!!

Only 994 commits in 2 years by 14 people?

[dingen]

After almost two years or work and 994 commits later made by only 14 contributors, the LTSP team is proud to announce that the Linux Terminal Server Project project released LTSP 5.2 on Wednesday the 17th of February.

That's about one commit per 10 days per person. Is this sort of number normal in the open source scene? It seems very low to me.

Re:Only 994 commits in 2 years by 14 people?

[CannonballHead]

Maybe they check their work before they commit it. ;)

On the serious side, I doubt most of them were working on this full time. You may look at it more like this: every 10 days, they had time to actually commit something they were working on while working on other [I presume?] full time jobs?

Re:Only 994 commits in 2 years by 14 people?

[symbolset]

It is if they're also teaching school. A lot of open source projects are funded by enterprises that pay programmers to improve the project and contribute back. There isn't a lot of call for that in LTSP yet - corporations find it easier to just license Citrix or Microsoft Terminal Services.

This may change as VDI initiatives take off for the power savings, security benefits and management economy. Terminal services on low-watt thin clients is hugely green. LTSP for terminal services, virtual desktops in KVM, plus dedicated servers for high-powered users makes a nice blended VDI solution that suits low-needs customer service people who only need a browser, all the way up to engineers - as long as everybody can use Linux. Management overhead is very low and security can be as high as you can get with network access terminals.

Re:Only 994 commits in 2 years by 14 people?

[Anonymous Coward]

The project is underfunded and all 14 developers had to share the same keyboard and terminal. On top of that one developer kept eating peanut butter and jelly sandwiches that gummed up the keyboard and he was always touching the monitor so it was harder to debug with PBJ on the screen. For the love of God please donate to this project or 5.3 will not be realeased before the end of the world in 2012.

Re:Only 994 commits in 2 years by 14 people?

[Jorl17]

I love peanut butter.

Re:Only 994 commits in 2 years by 14 people?

[bligneri]

Well, a large part of the job is to make sure that LTSP is properly supported ... by the distributions. Those changes are not, per se, in the LTSP code but in most of the distro code and not directly in the project code so I guess that it makes sense for such a project that integrates a lot of underlying technologies that have to be supported and working together :

• DHCP
• TFTP
• NFS (no more)
• NBD
• Pulseaudio
• X11 (X.org)
• etc. (to name a few)

LTSP is supported by Debian, Ubuntu, Fedora/RedHat, Suse.

On another level, another important effort has been done to provide enterprise grade thin client (LTSP-Cluster) and all those efforts happens outside the LTSP tree and are not accounted for in this changelog.

Re:Only 994 commits in 2 years by 14 people?

[MichaelSmith]

After almost two years or work and 994 commits later made by only 14 contributors, the LTSP team is proud to announce that the Linux Terminal Server Project project released LTSP 5.2 on Wednesday the 17th of February.

That's about one commit per 10 days per person. Is this sort of number normal in the open source scene? It seems very low to me.

They are probably using something old fashioned like CVS where all commits are globally visible and nobody can commit anything which might possibly break a branch. In mercurial I tend to commit every time I make a change and then collapse commits into logical patches before I push upstream.

Re:Only 994 commits in 2 years by 14 people?

[asdf7890]

That's about one commit per 10 days per person. Is this sort of number normal in the open source scene? It seems very low to me.

It depends on the size of the average commit. If most of them are small changes to single files then yes this is probably slow. But if a developer is working on a complex change then an individual commit could represent a significant number of man-hours developing, unit testing and regression testing before the commit. This is especially true if they are using some form of distributed source control whereby said developer has a local repository to keep inter-commit changes tracked in or if they are using a branch+merge arrangement (so the developer commits partial changes to a "personal" dev branch) and they are only counting commits/merges to the main branch/trunck in the above count.

Re:Only 994 commits in 2 years by 14 people?

[Anonymous Coward]

# of commits != progress

Re:Only 994 commits in 2 years by 14 people?

[symbolset]

A browser and a VT-100 terminal are all that a lot of customer service people need and should have. The limitation of using a web application prevents a lot of activity you don't want customer service people doing like installing applications, running scripts embedded in documents, etc. Web interfaces have come a long way.

Likewise networking and thin clients have come a long way since the days of Token Ring, which peaked at 100mbps in the late 1990s. Thin clients have gigabit network connections now and every port is switched rather than being part of a bus or loop.

Most especially servers have come a long way. It's not unusual to have a 1U server that runs 16 3GHz threads on 8 cores, or 12 threads on 12 cores, using high-bandwidth/high IOPs SAN or local storage and 10Gbps networking. Back then 1GHz was fast for a server. 1GB was a lot of RAM, and today 192GB is easily reachable. Next month we get the 12-core 2, 4 and 8 socket boxes for up to 96 cores per server. This is just the commodity stuff - I'm not citing the special purpose stuff like Sun and Itanic for the obvious reasons. Heck, these days the SSD hard drive in my laptop can do over 8K IOPs - I can configure a server to do well over a million. Storage infrastructure also enjoys the leverage of newer technologies that leverage abstraction in new ways. You can, for example, create "smart clones" of a desktop virtual machine which work as deltas off of a "standard image" and require almost no storage at all. As the user uses it, the smartclone image file on the SAN grows only as much as the data written. As soon as the customer logs out, their temporary data is erased and no storage is consumed - and they get a fresh image the next time they log in which improves security immensely.

So in short, time sharing was bad back then because you were sharing from a very shallow pool of resources through a thin straw. Now the pool is deeper enough, the straw is wide enough, to give the benefits we were promised back then and didn't see. The clients, the network and the servers all have the capacity to deliver an outstanding experience. Sharing is an even better idea now because the drives, servers and even individual processors or cores can power themselves down and up based on demand and keep a reasonable amount of resources available to handle demand spikes.

The question now becomes whether or not we can return to the cathedral - the ivory tower of precious resources husbanded and defended by a heirarchical information clergy steeped in knowledge and cloaked in the mysteries of keeping it running and making it safe. We needed the Bazaar to improve productivity when the infrastructure wasn't up to snuff, but it's proven a costly and vulnerable environment for business. Getting the end users to give up their local autonomy is not going to be a soft sell - it's going to be a long and ugly fight. IT pros can probably ease the transition by making the virtual or shared environment more open and faster than the local one until the transition is complete, and then shutting down the ability of end users to do unsafe things once the migration is complete.

Re:Only 994 commits in 2 years by 14 people?

[Eil]

I don't want to time share. Just like I don't buy a time sharing condo in Florida. Maybe you're both to young to remember Token Ring networks and true time share but they were SSSLLLOOOWWW.

Hello there ye from the realm of outdated misconceptions. Who told you terminal servers were slow? A few years ago, I set up a 20-seat Linux terminal server network. One terminal server (which was about as powerful as a high-end desktop machine at the time) was enough to handle all of the clients simultaneously and not break a sweat. We're talking P2-era technology on the client side. Each desktop was just as responsive as if the input devices were connected directly to the server itself. I talked to more than one person who absolutely could not believe that the applications they were using were actually being run on another machine over the network.

And please quit assuming that everybody but Slashdot people only need a web browser. That's one of the most arrogant and incorrect statements. Do you honestly believe that Customer Service people only need a browser?

Strawman argument, nobody said either of those things. Even if they were true, the point is moot. LTSP-enabled distributions provide complete Linux desktop environments. You get sound, access to local devices, and all of the applications that run on Linux. About the only applications I wouldn't recommend for terminal servers would be those with demanding video requirements like 3D games, CAD, and video editing.

In a previous job, our whole office ran off a terminal server and it worked great for years. I did system administration and web development, never had a single task that the setup couldn't handle. We even ran dual-screen on the thin clients and never had a problem.

I honestly believe that 95% of the posters on Slashdot either don't have a job or are trolls that live in the sewers because a good majority of you have no idea how WORK works.

Be sure you count yourself in that 95%.

Re:Only 994 commits in 2 years by 14 people?

[Daengbo]

Sorry, but it's you that doesn't know what he's talking about, since you're too "time share" phobic to find out what's really going on.

Give me an enterprise-class machine (disk access, etc., though two machines would be better) of he same caliber as a high-end desktop from today, and I can run 15-20 cheap diskless clients off of it in a Gbit, switched environment, with the same performance of a low-end desktop from today. 3D accelleration. All the desktop apps. Local storage and printer access. How does that work? The performance comes from shared application libraries among different clients and cached memory on the server.

Yeah, I've done this in production environment. I've done it in my business. I'm not a jobless troll. It works. It saves a ton of money. Users have no idea anything's different than a standard desktop, except that booting is five times faster, and when hardware fails, I can rip a client out, put a new one in, and have the client back up and running in 5 minutes. I fix the broken client on my schedule instead of holding up work for it.

Stop being afraid and learn some new tech.

Re:Only 994 commits in 2 years by 14 people?

[dingen]

Stop being afraid and learn some new tech.

You can say a lot of things about time sharing computing resources, but it aint exactly "new tech".

Re:Only 994 commits in 2 years by 14 people?

[Daengbo]

It's new to him, apparently. He doesn't want to learn about something that changed in the last two decades. (That point should be obvious since I talk about using LTSP almost ten years ago.)

By the way, I, too, used time sharing at university in the 80s, and it sucked. The mainframe was over-provisioned while hundreds of CS and engineering majors tried to code and solve advanced math problems on it at the same time. The failure of my university (and his, apparently) to do terminals correctly doesn't mean that they can't be done well. Fat_mike needs to figure that out.

Re:Only 994 commits in 2 years by 14 people?

[Anonymous Coward]

8 K IO/s on an SSD, which SSD Is that i get ~2K on my macbook pro ssd which is a

ocz vertex iirc. and you can build a server that does 1 million IO/s ? how ? ramdisks ?

Re:Only 994 commits in 2 years by 14 people?

[symbolset]

SSD: that would be Patriot Torqx M28.

Server: For that you need a server with a bunch of PCIe x8 slots and a bunch of the PCIe attached SSD devices. FusionIO is a popular vendor, but there are others. IBM has a project where they work on this stuff, but you can buy it off the shelf now. Costs are still pretty high on this one.

Re:Only 994 commits in 2 years by 14 people?

[Archangel Michael]

Who told you terminal servers were slow?

Experience.

It all depends on what is being "served" by the TS. However, I've seen huge servers brought to their knees by processes such as Powerpoint (or OpenOffice clone), or rendering images, or whatever sucking as much CPU as possible to run. Load that up by three or four people and now you have a TS brought to its knees. A server designed to host 30 to 50 clients suddenly can't support 10, all because people didn't include "Powerpoint" in the spec, because nobody heard of it when it was implemented, and a year later, someone hear of it, and now you have computers that don't function well for ANYONE.

If someone goes down the whole Terminal Server route, they best be understanding the dynamics of how people use computers changes and evolves, almost always to use MORE computing power, rather than less.

And to compensate for these changes, one ought to budget into the specification the upgrades needed to keep up with the increasing demands. Either that or start telling people "NO" when they want Powerpoint. And good luck with that.

This is not to say I'm against Terminal Servers, because I'm not. In places that have a limited demand for applications, a TS is probably an awesome solution for managing workstations.

Just saying you haven't experience it being "too slow" doesn't mean it doesn't happen. I've seen it happen, and it sucks when people expect a system to work as designed when the parameters of the system has changed.

Re:Only 994 commits in 2 years by 14 people?

[LordLimecat]

I honestly believe that 95% of the posters on Slashdot either don't have a job or are trolls that live in the sewers because a good majority of you have no idea how WORK works.

I know how work works, and one of our government clients hired us to set up a public-access computer center. Option A was to install deep freeze, antivirus, and tons of other lockdown crap onto each PC and then manage them individually, and hope none of the hard drives failed, or image them and outline the reimaging process for their local IT manager.

Option B was to simply put it all on a terminal server and PXE boot all the machines. Something goes wrong? Pull the plug and reboot it. Thin client dies? Throw another one in there, put the PXE boot floppy in it, and fire it up. Need to deploy software? Stick it on the server. Configuration change? Do it on the server.

I think you vastly underestimate the number of different use cases out there. Perhaps you imagine that every company's IT focus is structured the same; I know of several companies that could get all of their work done with nothing but a web browser (email access, report generation, file modification)-- and i DONT mean internet explorer+activeX.

I also know of a few people who have timeshares, and use them; somehow youve come up with the notion that timeshares are unilaterally bad as well, but then we've already established that all you can see are your own needs and preferences which youve taken to be representative of everyone else.

Re:Only 994 commits in 2 years by 14 people?

[symbolset]

Oh, BTW: I wasn't thinking RAMdisks, but they're still out there and they still rock just as they always did. I know a guy who's using them for some high-end work. I imagine for really high end applications like trading systems they use huge RAMdisks backed by flash memory, and good batteries. We were doing 1M IOPs on RAMdisk over a decade ago and it was hot stuff, I'll tell ya - but RAM is not persistent storage even when it's battery backed, so RAMdisk doesn't really count for storage metrics.

The drive I mentioned has 128MB of buffer RAM. I imagine that might impact the IOPs quite a bit with the testing configuration I was using.

New at HP is 1GB flash-backed write cache. Flash-backed write cache might be a good interim step between SAS/SATA attached flash drives and direct PCIe attached flash drives with huge RAM cache.

Some people are even using really absurd solutions like external PCIe, and shared PCIe. If you have the kind of problem that solves then more power to you, but that's kind of out of my comfort zone.

Re:Only 994 commits in 2 years by 14 people?

[thinkloop]

Flamebait?? That's a funny well placed reference. What kind of draconian moderating is that? Someone with mods fix it. (I'm not the poster, just a good samaritan)

Re:Only 994 commits in 2 years by 14 people?

[Anonymous Coward]

Thank you. Reckon I'll link to this. Simple, clean, no-nonsense remarks regarding a very old and useful technology; at the very least in /. terms ;)

But it's a start I'll use to motivate other's to realise that their arsehole's are quite sore from the previous 15 years of MS butt-lovin'.

It really is cool

[symbolset]

Yeah, you can do it without LTSP. But you don't have to be a guru to stand up an LTSP server and host desktops for thin clients so it's handy for the schools who use it. I've been using it at home for years to host desktops for guests because when the nieces and nephews come over they have incredible computer corrupting skills and need a platform that's less amenable to viruses than my kids' desktops and laptops.

You can also mangle the config to merge in DRBL, which allows me to netboot compute cluster nodes that I get at surplus if I want to do a little recreational number crunching or transcoding. I think it's pretty cool that we live in an age when an ordinary elementary school can have its own supercomputer and if their networking is up to snuff, join the ranks of the world's most powerful supercomputers.

But go ahead and rain on their parade if it makes you feel 1337.

Quiet in here...

[HoldmyCauls]

Not many comments yet, so I just thought I'd say "Huzzah!"

I'm a teacher for a catholic school on a tight budget with laptops with dying hard drives. Edubuntu has been a major lifesaver for me. I'll be checking out the improvements in the new version!

Re:Quiet in here...

[techno-vampire]

I'm a teacher for a catholic school on a tight budget with laptops with dying hard drives.

Has the priest given them Extreme Unction yet?

Re:Quiet in here...

[pnutjam]

Another good option from OpenSUSE. I have had better results with their releases. They tend to do better more reliable hardware support.

Word of Warning: Network Bandwidth

[fm6]

Terminal servers can work quite well — if you have the bandwidth. Nothing more frustrating than watching a graphics terminal update over a slow connection.

Re:Word of Warning: Network Bandwidth

[markdavis]

We ran 130 Xterminals (Linux machine thin clients) over switched 10-base-T with a 100-FL backbone for many, many years (up until 2 years ago). It worked just fine. The only thing that will kill the network is trying to play video or have Flash, neither of which we support.

Now we have 160 over switched 100-TX with 1000 fiber backbone. It is faster, but not THAT noticeable.

Re:Word of Warning: Network Bandwidth

[Daengbo]

It's designed to be used over a local, switched network. Is that normally slow for you? The standard now is 1Gb/s.

Re:Word of Warning: Network Bandwidth

[cynyr]

100Mb would seem fine assuming that it's on a proper(managed/smart) switch and not on a hub.

Re:Word of Warning: Network Bandwidth

[fm6]

Can you even buy hubs any more? In any case, you're forgetting the fact that all the systems connected to the switch still share the upstream connection to the server.

Re:Word of Warning: Network Bandwidth

[fm6]

1Gbs may be "standard" but there's still lots of slower connections around. If your building was cabled more than 5 years ago, it's probably only rated at 100 Mbs. Much older than that, it's 10Mbs.

It was 11 years ago that I encountered my first terminal server — and it was a painful experience. My recent experiences have been more positive, but of course these were all on much more modern networks.

Re:Word of Warning: Network Bandwidth

[fm6]

Oops. When I read "thin client" I assumed they were talking about those graphics terminals that currently misuse the term. If I'd RTFA, I would have noticed that this project was about X-Terminal software, which is a real thin client. One reason it rates as a true thin client: it doesn't require a lot of bandwidth. As you pointed out.

My bad.

Re:Word of Warning: Network Bandwidth

[willy_me]

Can you even buy hubs any more?

I believe that all of those cheap 10/100 switches are really two hubs with a switch connecting the 10mb to the 100mb. Technically, there is a switch in it so they call it a switch - but it acts just like a hub.

Re:Word of Warning: Network Bandwidth

[Alien Being]

Low bandwidth isn't what makes a client "thin". "Thin" refers to the amount of state and logic on the client.

X is fatter than VNC because it stores fonts, bitmaps and other data and it is responsible for rendering the output.

VNC, OTOH, doesn't even know what a font is, much less how to render it.

VNC usually requires more bandwidth, but X makes more network requests and its performance suffers considerably more than VNC over high-latency links.

Re:Word of Warning: Network Bandwidth

[Daengbo]

Five years ago, I was running twenty clients per 100Mb/s switch and terminal server, and there was no slowdown at all. Sure, a 10Mb/s non-switched environment is going to suck. That's not in any modern setup, though, and if you're going to move to a terminal server arrangement, network modernization is going to be in your budget for the program.

Re:Word of Warning: Network Bandwidth

[markdavis]

Originally, we did use Tektronix Xterminals. As the price of X86 machines plummeted, we decided to make our own using Linux.

"Thin client" is not an absolute, it is more a reference to where the applications are actually running. You could have a rather fat machine on a desk (hard drive, OS, etc), but if all or most of the user applications are being run on a host somewhere else, then it is "thin".

The project (LTSP), uses Linux as the base OS for creating machines for which the majority (or all) of applications are run elsewhere.

But I know what you are saying about the terms. It is about as meaningful as "netbook".

Re:Word of Warning: Network Bandwidth

[anss123]

I believe that all of those cheap 10/100 switches are really two hubs with a switch connecting the 10mb to the 100mb.

No. It's actually cheap hubs that are really switches because with today's tech it's oddly enough easier to make a cheap switch than a hub.

Re:Word of Warning: Network Bandwidth

[fm6]

Were Xterminals ever cheaper than PCs? I seem to recall that they were about the same price. Which had a lot to do with them not catching on.

My problem with calling graphics terminals "thin clients" is not the "thin" part, it's the "client" part. A client is something that's part of a client-server model, and passively acting as a network KVM is nothing like that.

Then again, Xterminals aren't clients either. As you perhaps know, they respond to requests from the application, which makes them the server in a client-server model.

Strictly speaking, only network computer ever qualified as "thin clients." But conceptually, Xterminals are close. And the fact that "thin client" now mostly refers to a remote KVM device is too well-established to argue with.

Re:Word of Warning: Network Bandwidth

[markdavis]

Yes, many Xterminals were cheaper than the typical fat X86 machines of the say day... and they still are. But many were not... It depended on a lot of factors. And yes, they would have been even cheaper if the volume had caught on.

Either way, I don't disagree with most of what you say- I think the terminology is all whacked. But, I think that is true with a lot of terminology in lots of things.

Re:Word of Warning: Network Bandwidth

[fm6]

Yes, many Xterminals were cheaper than the typical fat X86 machines of the say day... and they still are.

What? You mean somebody's still making them? I know NCD's gone out of business. Anybody else?

are there a windows client available?

[Anonymous Coward]

are there a windows client available?

Re:are there a windows client available?

[Daengbo]

You can use LTSP to boot directly from bare metal to an RDP login. Does that count?

Interesting, but...

[Anonymous Coward]

Is there any effort to separate X from XDMCP to speed up local X server? X (local) just doesn't seem as snappy as Windows. Does OSX use X for windowing?

Re:Interesting, but...

[micheas]

Is there any effort to separate X from XDMCP to speed up local X server? X (local) just doesn't seem as snappy as Windows. Does OSX use X for windowing?

X is reasonably snappy on a 50mhz machine with 64 meg of ram and a four meg of video ram if you are running blackbox.

I don't know what crippled hardware you are running on that makes X seem slow, but I suggest you pull something faster out of a dumpster.

Yes, I know that the 3D code for a lot of video drivers are pretty slow and incomplete. But that is not an architecture problem, it is a beta/alpha quality code issue.

Re:Interesting, but...

[Anonymous Coward]

try running a 2 Mpixels screen with that setup or even
something more modern like a p2

LTSP-cluster

[xzvf]

LTSP is an outstanding product that scales incredibly well compared to other virtual desktop solutions. While a little off topic, LTSP Cluster is an excellent addition to large scale LTSP deployments. https://www.ltsp-cluster.org/

N-W "Eye" & Site-Access Control?

[Anonymous Coward]

At least one school requires these features:

1. an admin tool (akin to "Network Eye? from long ago) to enable a teacher
        to follow progress, message, take control (if instructions are ignored) &
        assist/monitor a REMOTE (usually, in another room, at same facility)
        student/terminal (with up to 4 thumbs of terminal screens / page), AND

2. a way to strictly limit access to web sites (eg, to those needed for the
        assigned tasks and/or (eg, during free-use times) those deemed to be
        appropriate for access from school.

Only if both of these feature are available would some schools be prepared
to trial this system.

ARE THESE FEATURES ALREADY in the DEFAULT LTSP 5.2 ?

If so, are there any known issues with their functionality ?

(We'd not be able to approach the school if kids could find "workarounds"
to site-access control; & they'd still need to monitor & assist students'
working, in real time.)

TIA

Re:N-W "Eye" & Site-Access Control?

[stgraber]

iTalc can be used for monitoring ("Network eye"), it can autodetect LTSP thin clients and show their screens to the manager. Then the manager can lock them, do a demo or take screenshots. For limiting web access, it's not built-in LTSP but using a SQUID web proxy usually does the trick.

Re:N-W "Eye" & Site-Access Control?

[langelgjm]

We'd not be able to approach the school if kids could find "workarounds" to site-access control; & they'd still need to monitor & assist students' working, in real time.

Unless you're explicitly whitelisting sites, or you're preventing students from using SSH software or using their own machines, I'm sure you have kids smart enough in your school who know about ssh -D.

Re:N-W "Eye" & Site-Access Control?

[SharpNose]

Google "teachertool ltsp". It's part of K12LTSP.

Clients

[Anonymous Coward]

What Diskless Clients should we buy - most of them seem more expensive than a cheap Dell?

Re:Clients

[AVryhof]

http://www.newegg.com/Product/Product.aspx?Item=N82E16883103228

I bet these with the right config would work nicely. It's a shame they come pre-installed with XP.

Re:Clients

[jackflap]

And for UK buyers but with Linux-preinstalled: http://www.ebuyer.com/product/167153

Re:Clients

[Anonymous Coward]

Sweet - thanks (one per customer!)

Yes.

[Colin Smith]

Is it just simpler to to set up?

Yes.

You could think of it like not having to code yourself a word processor or build your own Linux distribution. Someone else has done all the work for you.

 

Re:ltsp problems

[Clover_Kicker]

100mb/s connection is NOT enough for a 1280x1024 desktop. just try to see a youtube hd video.

This setup is for work, not play.

Re:ltsp problems

[stgraber]

And that's why we implemented localapps. Running firefox as a localapp will let you do fullscreen flash just fine. As I mentioned, LTSP is either using X11 over SSH or SSH only for authentication. In the second mode, your credentials are sent securely but the actual X11 events are send unencrypted, so that's actually faster than any OpenVPN/IPSEC you may use.