Thanks a lot...Very Well Explained...!!!!
With Regards
Husain Yusuf Nagri
+971503827252
> Date: Mon, 11 Jan 2010 20:34:12 -0800
> From: nmets...@yahoo.com
> To: ltsp-discuss@lists.sourceforge.net
> Subject: Re: [Ltsp-discuss] Red Hat Enterprise Virtualization for Desktops
> vs LTSP?
>
> 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
_________________________________________________________________
Windows Live: Make it easier for your friends to see what you’re up to on
Facebook.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_2:092009------------------------------------------------------------------------------
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
