I had a chance to read a little more about the Red Hat Enterprise Virtualization for Desktops this past weekend.
First off, it's still in beta. I think I'll wait until they actually have more of the kinks out before I even consider trying it. It does indeed seem that it will probably require more powerful servers than LTSP, and possibly slightly more powerful thin clients. Scott had some very valid points about having to learn even more... Red Hat seems to be trying to get around this, and many of the same things that have been burdening LTSP developers for years -- like various forms local devices, with newer and more complicated ones coming out far too often for anyone to keep up with. It seems to me that Red Hat is trying to take care of this by having each user have their own desktop. It can be running on the server, or on the client (after having booted via pxe, etc.). They have an interesting way of provisioning the virtual desktops. Their desktop images have layers. They have a base image, and then each user has their own layer with their personal settings. The admin only needs to update the base image(s). It should be able to handle any of the local devices as if it were a regular linux (or windows) install, because (as they say) the only real difference is that the image is on the server (where it can easily be backed up or administered) and not on the client. They have SPICE, which automatically determines where the graphics should be rendered - on the server, or at the client. They're counting on this making multimedia work as it should. (And this remains a problem with *all* current remote desktop systems.) And they say they'll have an admin tool that will make it easy to manage *thousands* of virtual desktops. Red Hat -- being Red Hat -- of course, is taking an exceedingly complex way of going about all of this. Or at least, that's how it seems to me. But it'll be interesting to see if they will come up with a better mouse trap. I guess time will tell. When they get it out of beta, God-willing, I'll give it a whirl, and let you all know how it compares to LTSP. Thanks for all of your interest, and your posts. nico --- On Mon, 1/11/10, Scott Balneaves <sbaln...@legalaid.mb.ca> wrote: > From: Scott Balneaves <sbaln...@legalaid.mb.ca> > Subject: Re: [Ltsp-discuss] Red Hat Enterprise Virtualization for Desktops vs > LTSP? > To: ltsp-discuss@lists.sourceforge.net > Date: Monday, January 11, 2010, 3:27 PM > On Fri, Jan 08, 2010 at 08:24:34PM > -0800, Nicholas Metsovon wrote: > > > I'm not a big fan of RedHat, but they seem to have far > greater resources than most Linux projects. I'm kind > of curious if LTSP can benefit from any of this, and how it > will affect LTSP in the long term. > > Myself, personally (and I fully realize I'm in no way a > spokesman for LTSP), I > would prefer us NOT to "benefit from" this project, if by > "benefit from" we > mean "subsume even more technology under LTSP's > banner". Here's why: > > There's a couple of things that have been worrying me for > the last several > years. I'm not sure I can precisely define what I > want to say, but bear with > me. > > The first thing is the ever widening umbrella of "things" > in which LTSP > developers are having to become proficient in to be able to > support LTSP. LTSP > started out as a nice, simple way to connect to a remote X > server. Think old > style X terminals. It worked *really* nicely, because > it was simple: it did > one thing, and did it well. > > We've moved on from there. Now we have our own > display manager, we support > local devices, by writing our own network file > systems. We've crafted a > lightweight IPC using Xatoms for localapps. Now we're > going to have to talk > DBUS and PolKit in order to get things done. We're in > the process of writing > PAM modules to better clean up the code and support even > MORE things people > want (smart card auth, etc.) > > Throughout all of this, the range of questions we're having > to answer is > getting wider and wider and wider. Anything that even > remotely TOUCHES LTSP > now seems fair game for people to stop by the channel and > ask questions. > Classic case in point, today we're in there helping someone > with shell scripts > for setting up desktop links on all the users > desktop. This is OBVIOUSLY in no > way connected with LTSP, and I'm certainly glad we were > able to help this > person, but #ltsp is rapidly becoming (IMHO) a "black hole > time sink" for LTSP > developers and regulars. Not getting an answer in > #ubuntu or #debian or > #fedora? No problem, just wander over to #ltsp, they > seem to have a lot of > smart people over there who always answer questions. > > I don't know about the rest of you, but it's becoming... > worrying. And the > more we widen the umbrella, the more questions we > potentially have to answer. > > The second issue is one of (for lack of a better term) > "Project Lifetime". > LTSP is what LTSP is. If RedHat's come up with a > better mousetrap, something > that beats LTSP at it's own game, I'd be happy to let them > beat us. Or, they > have their product, and we have ours, and we co-exist > happily. But somehow, if > they've truly invented something better, I'm happy to let > them be better. > > This isn't a zero-sum game, and LTSP doesn't have to > "win". I'm sure the day > will come when someone comes up with a revolutionary idea > that supercedes > everything we've done. I guess what I'm saying is, > the old adage of "If I can > see farther, it's because I've stood on the shoulders of > giants", when the time > comes, I'll be happy to be the shoulders, and let someone > else see farther. > > Just my own, personal, 2 cents. > > In the meantime, back to writing pam modules. > > Scott > > -- > Scott L. Balneaves | Nature uses as little as possible of > anything. > Systems Department | -- Johannes > Keppler > Legal Aid Manitoba | > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer > Community > Take advantage of Verizon's best-in-class app development > support > A streamlined, 14 day to market process makes app > distribution fast and easy > Join now and get one step closer to millions of Verizon > customers > http://p.sf.net/sfu/verizon-dev2dev > _____________________________________________________________________ > Ltsp-discuss mailing list. To > un-subscribe, or change prefs, goto: > https://lists.sourceforge.net/lists/listinfo/ltsp-discuss > For additional LTSP help, try #ltsp > channel on irc.freenode.net > ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.freenode.net
