I think another significant factor is that XOrg is no longer being developed with our usage in mind. In the beginning, XWindows was developed as a REMOTE display. In an attempt to capture the Desktop PC market, I think much of the functionality that made XWindows suited for network based operation has been made a lower priority than the implementation of the eye candy to keep up with Windows Vista and Mac OS X. Many new features probably bypass any notion that the information needs to be passed across the network before display, causing problems with plugins like Flash and other 3D effects.
This is partially a long time rant for me because I feel that Business computing was on a much better path 20-30 years ago in the days of dumb terminals and the advent of XWindows. It was the PC that derailed much of what businesses need to stay efficient, and that is visibilty and control of their business data. It's not valuable to a business to have more eye candy on their work stations for their office employees. I'm not saying we should still be on dumb terminals with 80x25 screens or anything. I'm saying it would be nice to have the expenditures and wasted effort back that was the transition to PC's and back to Thin Clients. We would have AMAZING thin clients if business had never tried to depart from this paradigm. Jeremy D. Young Systems Analyst O'Reilly Auto Parts (417) 862-2674 x1858 Scott Balneaves <sbaln...@legalaid.mb.ca> wrote on 02/25/2009 03:53:19 PM: > On Wed, Feb 25, 2009 at 12:52:39PM -0800, john wrote: > > Hi all, > > > > One of the reasons I originally found LTSP compelling was the modest > > specs required of the thin clients. Lately I've been feeling like my > > flavor of Linux/LTSP (ubuntu) has entered the same kind of systems > > requirement arms-race that I thought I left behind when we moved away > > from workstations running XP. > > I used to be able to run PII's with 128 mb ram no problem. These days > > 256 Mb on the client seems to be the minimum and 512 > > is preferred. I still have lots of PII's lying around, and I suspect > > vast portions of LTSP's potential user base may be working with older > > technology as well. If the future of LTSP means you have to buy new > > hardware to use it seems like a much less compelling solution. > > > > Perhaps my complaints are not really LTSP related (I have minimal > > experience with other Distros with LTSP packages), and perhaps the > > "fat client" approach is an attempt to get around this issue to some > > degree. I am sure someone will set me straight if I > > am conflating two different issues. :-) > > > > So is LTSP 4.2 the answer for older clients, or is there something > > else to consider here? > > Well, there's several things at play here. > > Although the LTSP written portions of LTSP continue to remain nice and small > (i.e. ltspfs, ldm, jetpipe, etc)... > > 1) Base system requirements have gone up. Most distros are using their > "default" kernel for a thin client. The default kernel has a LOT of support > built in for things that aren't (usually) found on a thin client (RAID cards, > ISDN adapters, etc). This adds to bloat. > 2) With the move of the kernel to purge itself of absolutely *everything* that > can be handled in userspace, and push it out to udev/hal/whathaveyou, you've > now got more daemons running that you used to before. > 3) The stock udev that is used by most distros contain all the rulesnecessary > for all the drivers included in point 1, making udev function > "slower". If you > look at the boot up of a thin client these days, it's spending the > bulk of it's > time looking for devices in the thin client. Once it's done that, the rest of > the boot is lightning quick. > 4) Xorg has gotten bigger, with more devices, and more fancy bling. > 5) "The World" has gotten more complicated. On LTSP 3.x, I had old Netscape, > WordPerfect 8, and an IceWM window manager, Now everyone (at a minimum) > expects: > a) Local devices > b) Local sound > c) Flash > d) Anti-aliased TTF fonts > e) 1280x1024 minumum. > And people WANT: > f) Full desktop, with lots of animation > g) "Oh, yeah, and I want compiz too!" > > In the "old" days, you had an 8 meg video card, and it was fine, because "old" > netscape didn't try to cache things in the local X pixmap cache, and besides, > no one had high-speed internet, so everyone kept images to less than 50k > anyway. Now, people just post their 8M tiff's direct on the web page. Yikes. > > All of this conspires to drive up cpu somewhat, but ram more. > > I'm not sure what a solution is. Part of it may be solved by > distros offering, > or users posting instructions how to make, scaled down "light" versions of the > kernel, and udev rules, which will eliminate some of the bloat. > > People keep trying to turn back to 4.2, thinking that somehow, it's a panacea. > Like all nostalgia, it's a pleasant thought. A couple of days later, they're > wondering how to recompile the kernel because their ethernet adapter isn't > supported by 4.2, and oh, can I compile a newer version of X for 4.2since it's > only x.org 6.9 in there, and my new videocard isn't there, and hey, why do I > have to do all this fiddling to get localdevs to work, it just worksout of the > box on LTSP5, and how to I get sound in Flash again 'cuz I *NEED* that...etc > etc etc. > > As minimum specs for a Linux box rise (as they inevitably do) although a thin > clients will be substantially LESS, they're not going to stay the > same forever. > > That's my view, anyway. > > Scott > > -- > Scott L. Balneaves | I must have a prodigious quantity of mind; it takes me > Systems Department | as much as a week sometimes to make it up. > Legal Aid Manitoba | -- Mark Twain, "The Innocents Abroad" > ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _____________________________________________________________________ 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
