Στις 26/03/2012 12:54 μμ, ο/η Ben Green έγραψε: > I don't think this setting -color depth- should be conditional, if > there's going to be a default, it should be the same for all, > otherwise it gets confusing.
I strongly disagree; the default should be to try hard to work in all cases. That's true in other lts.conf options already (e.g. NBD_SWAP was always automatically enabled for clients with <=48 MB RAM), and in other environments too (e.g. if gnome-shell doesn't work for you, you automatically get gnome-fallback; if unity-3d doesn't, you get unity-2d; if your screen is small enough, you get kde-plasma-netbook instead of the standard one; etc etc). > Some chipsets respond very differently to > different color depth settings, and so it would be bad for beginners > to find that when one setting changed when another changed, possibly > resulting in seemingly broken clients. > > For example, we have clients which just don't have the RAM for 32-bit > modes. We still might want to run local apps on them though. Changing > the bit depth when we changed to a local apps set up would cause X not > to start suddenly. I'm not proposing to force X_COLOR_DEPTH=32 when LOCAL_APPS_MENU=True. I'm proposing to leave the default empty value there, which in this case would default to 16bpp. > We also have old intel clients where OpenGL only works (albeit in a > limited fashion) on 16-bit color modes. A conditional change in bit > depth would be confusing in this case. Why doesn't any GL now work? > > These are only two examples but I'm sure there's more. In all the cases you mention, the automatic color depth would either solve the problem, or not have any bad effect at all. Can you think of an example were it would do harm? > Its not really a big deal for me, I can, and do, set the bit depth for > the installs I do, but I don't think the change is productive. The > simplest solution is the current one, set a reasonable default and let > the administrator choose. > > A note in the documentation would be more appropriate if we want > administrators to be choosing appropriate bit depths. If an administrator has 30 thin and 30 fat clients, he'd like it if they worked as well as possible out of the box, instead of having to put [mac:address] sections in lts.conf for each one of them. > Having the conditional as part a =auto option is great though. > <snip> ...otherwise it gets confusing. In both cases, the "auto" logic would be documented, so it wouldn't be confusing. The only question is if we want the default value to be "auto" or not. Since you mention that the "auto" default wouldn't have any bad effects for you, and all the others mentioned that it would have good effects for them, let's wait to see if it'll actually have bad effects for anyone here. If not, we can make it the default. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _____________________________________________________________________ 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
