Re: [ilugd] Minutes of meeting (18th January 2004)
On Mon, 2004-01-19 at 19:42, vivek khurana wrote: Hi! Everyone Here are the minutes of january meeting of linux user group delhi, conducted at Faridabad Industry association. I had tried to be serious at the places where important things are discussed. So here are the minutes of meetings Have updated the www.linux-delhi.org site with minutes and some press clippings. Ashwin...where are you? You also need to move the event (December meet) from upcoming event to recent event so that the next upcoming event is highlighted. -- Sudev Barar Learning Linux ___ ilugd mailing list [EMAIL PROTECTED] http://frodo.hserus.net/mailman/listinfo/ilugd
Re: [ilugd] Minutes of meeting (18th January 2004)
anyways, what is exciting is, that using thin-clients, several people could simultaneously work on such demanding tasks through a centralised high-powered server, which in turn could throw its back-end processing to a farm of renderers or grpahics processing nodes, if need be this part of ltsp really excites me. :-) LL LTSP or NO LTSP. Xwindow protocol is a way of sending keypad and pointer events to the node which is actually running the application. The major advantage of such scenario is low-processing power clients and underline highly effcient /underline usage of resources like memory/processing power/secondary memory on underlineone/underline node. What I do'nt understand where you got the idea of cluster or render farm on backend. You can refer to an article in Network Computing about thin client solutions few issues back. Xwindow protocol has no (free) version of load balancing mechenism. So multiple X Application server may not be possible as far as my knowledge goes. There are commercial solutions with X protocol (load balanced), one can take a look at that, but that means the cost benefit between running X to something like citrix. BTW there are better ways of doing render farm/ image processing using a protocol called RENDERMAN from Pixar. I think you must have come across that name. This we can further discuss off-list if you like Supreet ___ ilugd mailing list [EMAIL PROTECTED] http://frodo.hserus.net/mailman/listinfo/ilugd
Re: [ilugd] Minutes of meeting (18th January 2004)
On Tue, 2004-01-20 at 16:39, LinuxLingam wrote: anyways, what is exciting is, that using thin-clients, several people could simultaneously work on such demanding tasks through a centralised high-powered server, which in turn could throw its back-end processing to a farm of renderers or grpahics processing nodes, if need be See the openmosix howto on the ltsp sitewant to implement such a cluster? -- Sudev Barar Learning Linux Address: D10 NH2, Faridabad 121001 Tel; +91-129-5021588 ___ ilugd mailing list [EMAIL PROTECTED] http://frodo.hserus.net/mailman/listinfo/ilugd
Re: [ilugd] Minutes of meeting (18th January 2004)
On Tue, 2004-01-20 at 16:39, LinuxLingam wrote: On Tue, 2004-01-20 at 11:02, Supreet Sethi wrote: Sorry but should have changed the topic / subject for a new thread. -- Sudev Barar Learning Linux Address: D10 NH2, Faridabad 121001 Tel; +91-129-5021588 ___ ilugd mailing list [EMAIL PROTECTED] http://frodo.hserus.net/mailman/listinfo/ilugd
Re: [ilugd] Minutes of meeting (18th January 2004)
On Tue, 2004-01-20 at 17:51, Supreet Sethi wrote: What I do'nt understand where you got the idea of cluster or render farm on backend. You can refer to an article in Network Computing about thin client solutions few issues back. [snip] render farm on back-end to run distributed rastarization using stuff like renderman, or check out blender3d.org for more info. also do note that these days, hollywood movies use linux heavily. ltsp makes it more exciting. rather than give high-end workstations to a team of artists to create cells and stuff, let them all work concurrently on a centralised server (either on the same file, or on different files that make up a large project, using ltsp, and let the ltsp server handle rendering and ray-tracing and stuff to have things sped up BTW there are better ways of doing render farm/ image processing using a protocol called RENDERMAN from Pixar. I think you must have come across that name. This we can further discuss off-list if you like :-) LL ___ ilugd mailing list [EMAIL PROTECTED] http://frodo.hserus.net/mailman/listinfo/ilugd
Re: [ilugd] Minutes of meeting (18th January 2004)
AFAIK giving artist a PC/MAC/(or any thin client solution) platform at any cost does'nt really matter. The central compute server cost anyways is too high in comparison. Example of costs: a normal via c3 based PC with disk can be assembled at 10,000-15,000. A normal compute node from a cluster vendor would comes out at 5,00,000 - 25,00,000. And for a motion picture you would require 10-100 of such machines. Cost quotes come from: eSys which is vendor of thin PC. Cluster costs derived from HP, IBM sites (Power4, IA64). Racks cost a seprate Cost effectiveness is not a debateble point in case of LTSP being used for studios. So lets go on to other points then (for and against) diskless solutions Management- Administration and management cost definately is much lower in case of LTSP or any thin client solution. But that also means, one needs to standardize on certain applications, like choosing Gnome as desktop solution, galeon as browser for example sake. Will a artist (graphic artist) allow somebody to control how underlinehis/underline desktop would look like. If not, then central management point also goes for a six. Renderman protocol does not specify that it could only be used with local application. One can directly call remote render farm from a underline cheap and smart /underline host, and get a good performance since most of the network traffic would only be renderman calls. Which in case of LTSP would also include X protocol and NFS request. So anyway cost benefit which I am not to sure there is, would be offset by the costly network infrastructre needed for accomodating X protocol, NFS and Renderman request. PS: The links you specifed are too preliminary in terms of details regarding Renderman. For detailed specs of Renderman protocol, there are various books on Amazon. For cluster vendors who provide RenderFarms which are compatible to RenderMAn protocol: http://www.terrasoftsolutions.com/ Tough there are many others also. I am not doing advertisement for this company Supreet ___ ilugd mailing list [EMAIL PROTECTED] http://frodo.hserus.net/mailman/listinfo/ilugd
Re: [ilugd] Minutes of meeting (18th January 2004)
archaic operating systems. During his introduction Kishore 'treasurer' Bhargawa reached the venue. So he was the next one to be introduced. Kishore started by snip“boasting”/snip that he had being using linux even before Linus Trovalds and how he got linux kernel in yr 1992 in India. I did not say that Raj did! He advocated the redhat unstable fedora before taking his seat. The Not really advovated, just a suggestion. Overall it was fun even though thin attendance! Cheers...Kishore -- Last guys don't finish nice. -- Stanley Kelley, on the cult of victory at all costs ___ ilugd mailing list [EMAIL PROTECTED] http://frodo.hserus.net/mailman/listinfo/ilugd
Re: [ilugd] Minutes of meeting (18th January 2004)
Just in relation to (patent) color-depth formula by Raj Mathur. Color in applications are based on colormap that the application chooses or it inherits from Xwindow. These colormaps are really indexs maintained by the video card for colormmaping. These colomaping algorithms vary from video card to video card. And driver takes care of the mapping. So there is in most cases a direct relationship between color depth used and the video memory required but that cannot in most cases be expressed in single formula. Another aspect of concern in terms of video memory is video caching. Application can have a double buffered output. Some application like ones which use OpenGL rely on the library for handling the double buffering. In most gaming video card the library uses the video memory rather the RAM for doing double buffering. That increase the requirement for video RAM. Sudev showed that you need only 2MB of video memory to run LTSP client. At this juncture RAJ came up with following formula to decide the video memory required (resolution * no. of bits of depth)/ 8 Following the invention of formula and nomination for Raj for Nobel Prize in mathematics, sudev described how to setup LTSP server and clients and showed how policy manipulation on the server is reflected on each client. After description, there was a live demo of LTSP client boot. The presentation continued with demonstration of export features of openoffice. This presentation ended with discussion of cost involved in setting up LTSP project. Supreet ___ ilugd mailing list [EMAIL PROTECTED] http://frodo.hserus.net/mailman/listinfo/ilugd
