On Tue, 2005-04-12 at 01:21, Craig White wrote: > My understanding of k12ltsp was a sort of turnkey install of a ltsp > server/client for the k-12 users. The point is that you install a packaged distribution and it comes up working. It's the same reason that all other programs have been RPM packaged. > Freeing k12ltsp from the Fedora (or > RHEL) distribution would in essence duplicate the ltsp project, be > confusing and lose the turnkey singularity. Once installed, every linux distribution is mostly the same as every other, minus some preferences and politics. Supporting another distribution is just a matter of some duplicated work in the packaging and that's been done for hundreds/thousands of other programs. Why should ltsp and the educational program bundle be different? > In fact, when you previously mentioned the efforts of 'some' to > standardize ldap on k12ltsp - I knew that you were speaking of David > Trask - an educator on the east coast who was struggling to provide a > turnkey set of scripts to implement a singular visioned openldap > implementation based upon samba and IDEALX scripts and I suggested that > though his idea had merits for his purposes, it was limiting rather than > enabling and if implemented by unknowledgable administrators, would > create a class of users utterly incapable of solving problems, incapable > of implementing wider usage and rather tunnel visioned and the worst > thought of all, creating a network where no one could log in and no one > could figure out why. I didn't understand your position then and I don't understand it now. A packaged, scripted install of an authentication system is no more or less likely to fail than any other component in a linux distribution, including the kernel and device drivers. None of those are perfect and people who don't understand them still manage to use them and survive failures by following the advice of others with identical installations. Can you explain how LDAP differers from (say) X in terms of not being usable when automatically installed? Or how administrators would be better off building a custom solution which will have unique failure modes instead of using exactly the same as a large number of others so problems have a common solution? > In summary, I find the > IDEALX scripts rather arcane, worthless for my purposes and don't use > them except in the situations where I need to 'vampire' an NT server > over to a Linux based system with openldap backend. I don't recall that you mentioned a better alternative. If there isn't one, then it's still better than nothing or unique customization. For the k12ltsp purposes (which seem pretty general to me) it appears to be working fine. > My point in covering > this ground again is if k12ltsp loses it's singularity then what would > the project goals be? I'm not sure I understand the question. It is a matter of packaging a few extra things that are missing in the distributions. Why shouldn't they be packaged for as many distributions as openoffice is? The packaging and inclusion serves the same purpose. Being able to net-boot a thin client is a pretty generic application and the educational apps are just like any others that you may or may not want to install. > But bringing this full circle - I don't know what k12ltsp values > most...if it were stability, longevity and continuity, then the > CentOS/RHEL base totally makes more sense to me than Fedora Core 3 as it > would appear that based upon history, Fedora Core 3 will EOL somewhere > between September and October - relying upon fedora-legacy for updates - > which may be OK since it would seem that FC-3 would be a very good > choice for longevity by fedora-legacy - provided you can get 're-spins' > of the iso's ;-) Since the thin clients run their desktops on the server, having current applications is pretty important. RHEL/Centos 3.x would have been very outdated for a very long time had that been their only choice. 4.x would be OK now, but seems likely to repeat the cycle. So far the problems in practice with Fedora have almost all happened during the install. Many cases were mentioned on the mailing list about servers that worked with one version failing with the next (and I have my own list of those). However, once installed, Fedora has proven as reliable as any other distribution. > As for your notion about CentOS4 not being 'as good' as Fedora 4 - It's > never a black and white issue is it? Seems as though there are pluses > and minuses for each direction. Yes, but the problem comes from bundling the OS/server side with the user applications as much as anything else. Linux desktop applications are evolving rapidly while the OS/server apps have been usable for years. Locking application version-levels to a slow release schedule just isn't going to work very well. Likewise, doing version-level changes in OS/server items on a fast schedule has its problems. A compromise is to put the nfs/samba shared home directories and authentication system on a stable base so the k12ltsp servers that provide the desktop apps can be re-installed frequently with little custom setup. > There are of course, other options than Fedora - as you know. Ubuntu looks promising. We'll have to wait to see if they can manage a fast release schedule without sacrificing stability. At least it will be interesting to see what happens if you don't separate these goals. -- Les Mikesell les@xxxxxxxxxxxxxxxx
