[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: Attn : Dave Jones Re: I just want one more option in the FC Kernels (Dave Jones)
- From: Les Mikesell <lesmikesell gmail com>
- To: For users of Fedora Core releases <fedora-list redhat com>
- Subject: Re: Attn : Dave Jones Re: I just want one more option in the FC Kernels (Dave Jones)
- Date: Tue, 12 Apr 2005 11:33:38 -0500
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
> 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
> 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
> 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
les futuresource com
[Date Prev][Date Next] [Thread Prev][Thread Next]