Will Novell Adopt The LTSP Project?

SafeTinspector writes "Yesterday I attended a Novell/HP Linux seminer "Delivering & Deploying Linux Across the Enterprise" Among the boring and expected stuff, the Novell representative had several slides in his presentation claiming that Novell is going to get heavily involved with LTSP (Linux Terminal Server Project) to bring policy based security and administration to the LTSP similar to those found in Microsoft and Citrix terminal servers--probably through their venerable Zenworks product line. Also heavily hinted at would be an install wizard provided by Novell that would greatly simplify the installation and configuration of LTSP, which is currently quite complex. I can find no hard information about this on LTSP or Novell websites, nor any information within Google newsgroup search. Does anyone know more about this? On a side note, the laptops of both the HP rep and Novell rep were running SuSE Linux Desktop with Ximian XD2 installed and the presentation was made using OpenOffice Presentation."

LTSP .... Complex installation?

[Anonymous Coward]

1. "Also heavily hinted at would be an install wizard provided by Novell that would greatly simplify the installation and configuration of LTSP, which is currently quite complex"

2. Also config files are very very hard to edit and may inflict brain damage to anyone not using a nice "central" GUI.

3. Uh? Have they even installed LTSP before?! This might be the simplest installer ever of a Linux based "product". Also, it comes with idiotawakening documentation.

4. ....

5. "Beam me up scotty!..."

Re:Has thin-client computing come of age?

[kabocox]

It's been hyped since the mid-90's, but thin clients have never really caught on in the corporate environment. Why is that?

No, it is because tons of managers that just need IE, Outlook, and Wordpad, opps Word, and Access won't stand it. Managers have to have a scanner, digital camera, video capture cards, and dual monitors. It doesn't matter what they are managing they approve the budget. If it wasn't the manager, it would be the IT guy or the desktop publishing/web guru that needed it. The managers would generally argree that they need to lock down and micromanage all their employees. They want all that on the same platform as all their toys.

Thin clients should be on almost every business desktop. Other than call centers, I'd doubt that will ever happen. Remember if it was good enough for the manager it is good enough for his sec. or assistant.

Re:Why all linux

[kelzer]

At the risk of getting modded down myself:

Hey moderators - please read the moderator guidelines, which state "Concentrate more on promoting than on demoting" and "Average Comments might be slightly offtopic, but still might be worth reading. They might be redundant. They might be a 'Me Too' article. They might say something painfully obvious. They don't detract from the discussion, but they don't necessarily significantly add to it." The parent post fits into this category, and as such probably already had an appropriate score of 1.

If your gut reaction is to mod something down, maybe take a look at the poster's history. This guy is new to Slashdot, he's already posted some worthwhile things. His only other negatively modded post was flagged redundant (another overused moderation). I don't think he meant anything by this post. Yes, it's off-topic, but did it really deserve to get slammed down to -1, the same score as this post? [slashdot.org]

Please use your mod points more constructively. There are some good posts out there that deserved to be modded up more than the parent post deserved to be modded down.

Thanks.

Re:Reinventing X?

[b17bmbr]

no, X doesn't suck. it's based on a client/server model when all computing was networked. the computer on every desk mentality eminated in redmond. X works great across networks. in fact, instead of LTSP, i just used a singe X server and had several X clients running in my classroom last year. (i am at a new school this year.) i had a P3/933 w/512MB running 7 X clients, OO.org, moz, etc., without a hiccup. in fact, i had a knoppix boot cd that i could pop into any old box on campus and get X from anywhere. freaked some people out. X works great across networks. it doesn't suck. most of X's problems are driver related. hardly its fault. just learn how to make it work well.

Re:LTSP Compression

[moonwind]

And tell me what exactly are the bandwidth requirements of X?

Actually, the remote X problems aren't so much the bandwidth (which *is* important) but much more the "roundtrips". Depending on link latency each X protocol "request" by the X application client, that solicits a "reply" from the X server, introduces additional wait cycles. There comes a point where increasinb bandwidth doesn increase speed: you sit there with an empty pipe and waith for roundtrips to finish....

I hate to say it, but Citrix with their ICA, Microsoft with their RDP and Tarantelly with their IAP are all doing a much better job here and use far less bandwidth, making their stuff even work over modem links..

Overall, roundtrips make X feel very sluggish across WAN or low bandwidth links.

This paper [linux-kongress.org] gives a few good examples and figurs about plain vanilla X and NX-enabled X:

• a Mozilla start-up alone produces nearly 6.000 round-trips and needs more than 7 minutes to complete over a 9.600 baud modem connection. With the help of NX, the round-trips are boiled down to a few dozen, and a startup may only take 20 seconds over the same modem link!
• a full-screen KDE session transfers 4.1 MByte of data over the wire, if it is run over a vanilla remote X connection. Run it over NX, and the second startup data transfer volume is down to 35 kByte only! You can run KDE sessions over a 9.600 baud modem link and have a responsiveness which is better than TightVNC over a crosslink cable hooking together two boxes only 1 yard apart.
• overall compression/speed gain is 70:1 (on average, across various applications), but can easily achieve 200:1 and more for some applications, like Web browsing.

To me, the GPL'd NX from NoMachine [nomachine.com] are the saviours for X and remote X connections. Finally someone has created a plugin addon to existing systems, which lets the Unix world compete on par with stuff like Citrix (which, strangely, is now embraced by Redhat). NX is giving a bright future to ubiquitous desktop computing based on Unix. What's best: it can even access Windows sessions (via RDP) with a 2- to 10fold speed increase over plain rdesktop sessions.

I am looking forward to see their session "de-tach and re-attach" feature, as well as their "session migration" (leave office, go home, tease the baby, have dinner, and finish your work via a remote session from home by dialing into the very same destkop that you left back at work). ;-)

Interesting... very interesting

[tulare]

Sometimes it's hard not to kick oneself for being an early adopter. I've been successfully deploying LTSP labs at work [k12.or.us] this year using SuSE 9.0 as a base system, and the project has been a success, but it's been a heck of a lot of work. As we're deploying these as student lab computers in a K12 environment, lockdown is key, so I've had to learn (and make good use of) the KDE Kiosk API [kde.org], and of course this is before the Kiosk admin tool [kde.org] became available. Additionally, we have an Active directory with accounts for all secondary students, so I got to learn how to compile, install, and configure Samba 3 to get winbind to do some of the tricks I needed it to do besides just auth. Also, our primary students don't have an account of their own but rather use a shared school account, and Mozilla has that very annoying profile problem when a user tries to run multiple instances of it, so I had to write a wrapper [k12.or.us] so that it could run sandboxed (which also provides the benefit of keeping the kids from setting bizarre configurations which are then replicated to all the other users as they are wont to do in our other labs).

All in all, I'm kind of glad I did all this work by hand - I learned a lot, and most of it is now very easy for me to do. On the other hand, had the rumoured deployment tools been available when I started the project, I would have jumped on that and quick. I'm frankly not sure which is better in the long term, but I know it would have been faster to just click'n'run =]

One last thing - before someone flames me for being stupid and not just using K12LTSP, I have to say I tried it, and didn't like it - for one thing I needed more flexibility than was provided by K12LTSP, especially where AD auth comes in, and besides that, as a matter of preference I like what the KDE Kiosk api provides, and we all know just how much Redhat-based distros Don't Support KDE =] In the end, I got to know the system a lot better, and can do a lot more with it than I would have been able to do under a K12LTSP system. This isn't to disparage the effort and amazing work produced by the K12LTSP team - they really do have an excellent product and I recommend it wholeheartedly for K12 staff needing to get a fast deployment out - it just wasn't the fit I needed for this project.

Re:MMMM....LTSP goodness

[Citizen of Earth]

The implications of a Novell LTSP adoption almost had me drooling.

It'd be neat if they can line up a manufacturer of tiny, stripped-down, solid-state PCs that boot off the network and run a Linux-based X server. If they could get the price under $100 per box, it'd be funny to watch Microsoft and Novell bid on a big installation contract. The Microsoft bid would include a full Windows PC on every desktop and various servers, and the Novell bit would be for these mini-boxes and a few servers and open-source software. The Novell bid would be for ten times less than the Microsoft one, the desktops would be rated to run unchanged for 10 years, and would require about one-tenth the amount of permanent admin staff.

I see this kind of computing as inevitable because of the incredible savings in money, staff, and security, and probably the only reason it hasn't happened yet is because Microsoft is still into the "Computer on every desktop" idea. The paradigms, they are-a shiftin'.

--
"A stuffed penguin on every desktop."

"X" versus "Frame Buffer" is a tradeoff

[Kunta Kinte]

Yes, and I was talking about bandwidth, not the particular technology. An RDP session with bitmap caching running at 800*600*16bpp or 1024*768*8bpp is completely usable with the bandwidth of a 28.8 modem, whereas X is often unresponsive over a 604/128 DSL line.

This argument always comes up.

X uses and alternative approach to network transparency which comes with the trade off of higher bandwidth. The advantage though, is much less load on the servers.

Framebuffer based solutions eg. RDP are a joke when considered as a means of deploying applications to large groups of users.

You might end up with configs like 10s of users per server for even simple applications simply because all the rendering has to be on on the servers.

In the long run RDP is very expensive because of the equipment cost.

While with X, with the rendering offloaded to the client, happily chugging along.

Personally I think the X approach is a lot saner. Why render the entire application on the server when you have a client that probably can easily do this rendering as well? ...If you have the bandwidth, that is.