Re: LTSP e DRBL toghether ?
On Friday 6. July 2007 16:22, Petter Reinholdtsen wrote:
> [DRBL] sounds very much like what we call Diskless Workstation.
DRBL is practically the same as LowFat Clients (Diskless Workstations) on
LTSP according to DRBL FAQ:
My first argument is that technically duplication is totally doable in a
Skolelinux environment. Skolelinux has pioneered the Custom Debian
There are different needs in different parts of the world. Now LinEx in
Extremadura teams up with the Skolelinux/DebianEdu effort. They will
certainly include their choices, and build their regional CD to the benefit
for everyone. We are shearing architecture and applications, but does
different things in certain areas. In that scope DRBL is a do-ocratic effort
we should welcome.
If people want that in Taiwan or other regions or countries, make a fully
automated Debian package, making a zero configuration install on a school
server. Skolelinux has a goal of automation, reducing time and effort for
teachers when setting up and maintaining school or municipality wide computer
There are also other technical and practical things to consider.
First LTSP allow both "old school" Thin Clients and LowFat Clients with same
technology. It seems that DRBL don't support both way of running software,
running apps at on the server with Thin Clients -- or running apps on the
client with LowFat (Diskless) .
If DRBL get introduced as a replacement of LTSP, the Thin Clients will not be
supported. If DRBL and LTSP co-exists there will be a duplication of effort
on the LowFat side.
Second a lot of schools already has huge quantities of machines with 160-300
MHz machines with 32-64 MB RAM. They want a seemless transition to LowFat
(Diskless) clients with full multimedia support. Supporting both the "old
school" Thin Clients and LowFat are mandatory.
A new login manager was introduced in an earlier version of LTSP requiring 50
MB RAM. At some schools that killed of half of the thin clients with just 32
MB RAM. That was not good. This schools continued use of the first Skolelinux
since it had a low memory intensive LTSP. They will postpone upgrading to
LTSP are supporting low memory clients again.
Third I suspect the specs are pretty similar when it comes to the number of
client you get with DRBL and LowFat Clients (Diskless). Numbers from Norway
show that you can connect 150 LowFat Clients on a reasonable server with a
100M/bits switched network. Other schools running 50-60 thin clients on a 4
GB RAM server, and does a stepvise introduction of LowFat (Diskless) clients,
running this from the same server. Some schools got more than 250 thin
clients, moving slowly over to LowFat (Diskless).
Forth todays schools expect multimedia and OpenOffice.org support on PC's.
Most schools also uses Firefox. Both OpenOffice.org and Firefox uses a lot of
memory. Then >800 MHz CPU and 256 MB clients with swap is more appropriate
than machines with 450 MHz CPU and 128 MB RAM recommendation in the DRBL FAQ.
Fifth argument is just practical. In Debian there are a lot of technology
duplications. There are several desktops, e-mail clients, file systems and
web browsers. One of the goals for Skolelinux is to reduce complexity. When
we first started Skolelinux in 2001 we installed several different browsers,
text editors and such. There were several objections to that:
-- Teachers got in trouble because they got confused by small differences in
the user interface when helping pupils using different application doing
allmost the same thing.
-- Pupils got confused by different support for flash and video in different
browsers. Some browser supported flash, Java and video, other had partial
-- At meetings talking about the 75 cool pedagogic programs, some people
pointed out that there was no need for both OpenOffice.org and KOffice. They
did not get the fact that KOffice is excellent for younger kids because of
it's simplicity, where OpenOffice.org are more suited for kids in 5-6 grade
It's totally doable to explain some of the duplication of applications for
teachers, especially at the lower grades consering an office application. The
most conservative teachers at secondary schools we got in some more problems,
because several of the teachers at this level believe computing is about
office work, not teaching. But when it comes to infrastructure we need to be
-- Technically duplication of technology, especially on the server side will
increase complexity for teachers who maintain the school server. It will
introduce additional choices. Teacher in most countries I've visited got 2-4
hours a week to maintain a school server serving 50-150 client machines for
300-400 pupils and teachers. Introducing more choices also means more work.
Then a Custom Debian Distribution approach will be more suited.
Skolelinux project manager Norway