Re: edubuntu
Hi Knut,
I'll just restate my position in case anyone gets the wrong idea. I am a
big fan of debian and debian-edu. I think you guys are doing a great job.
However, in trying to get a project to work, I have reluctantly chosen to
use Edubuntu. I do not wish in any way to offend or annoy the people
working on this project. Hopefully by explaining my reasons for moving to
Edubuntu, debian-edu might gain a little by constructive criticism. On the
other hand, some of my reasons may not apply to debian-edu users at large,
in which case it would be folly for the project to try to suit a minority
at the expense of the majority.
I appreciate also that debian-edu is a do-ocracy and that I must attempt to
scratch my own itches to some degree.
Apologies in advance for the length of this mail.
On Sat, 29 Jul 2006, Knut Yrvin wrote:
> Lørdag 29 juli 2006 14:21, skrev Gavin McCullagh:
>
> > 1. Ubuntu has produced a clean, well-honed desktop. Debian has not.
> > This is a combination of menu organisation, hotplug stuff, artwork
> > (arguably) and other issues. Edubuntu and Debian-edu are pretty much
> > inheriting these. This point weighs very highly. We have teachers
> > coming from the Mac and Windows platforms. Impression really is
> > _very_ important. Personally I now use Edubuntu on desktops and
> > Debian on servers.
>
> Schools have turned on support for USB-sticks on thin clients with
> Skolelinux. ....
As this is probably the most important point for us, I'll just clarify.
Although I mentioned the word hotplug, I'm really not talking about USB
sticks working here. I'm talking about having a clean, tidy desktop with
simple, organised, unambiguous menus.
I don't wish to harp on because I'm certainly not the first person to say
this about debian. I'm not at all an expert in interface design so I would
have difficulty describing in detail what needs to be done. However, I
believe it is clear to anyone when it's done right and when it is not.
> Thats totally true. In Norway the company InOut that sells Skolelinux
> installations with server(s) and a lot of client's, they does small
> adjustments to the menu, and removes and installs the software the
> schools expect:
Which is backwards and time-consuming. I really think it's important to
choose one and stick with it by default. Those who have different
requirements should then be able to add extra packages. When you remove
the default packages, meta packages go with them and upgrades become more
problematic as I'm not really running debian-edu any more. Equally if you
use backports and unofficial packages you also deviate from the supported
norm.
> It's more a pedagogical reason I believe.
>
> A lot of teachers in 1-5 grade in primary school perceive OpenOffice.org
> to be an uninteresting and to complicated application to use for
> teaching.
You are probably right about this. This may be where our needs differ from
those of other schools. We're using our thin clients more for teachers
than students. Students are taught ms office apps in windows (not my
decision). We need to give teachers best interoperability with others
which to me means OpenOffice. My decision is obviously based on our needs
not those of schools in general. This might not therefore be a good data
point for a general decision.
> I've tried to promote the need for easy adjustable profiles for different
> grade levels a couple of year now. Luckily the new user admin system for
> Skolelinux will have a plug-in that give the teacher or the schools
> system admin the possibility to tailor the menu for pupils in different
> grades:
Do you really think hiding things from the menu is the answer to this? Do
many schools really want to use two Office suites? So much that you would
install both by default?
> http://wiki.debian.org/DebianEdu/CipUX
I don't mean I don't value CipUX. I just think it shouldn't be necessary
to use CipUX to clean up the desktop on a default install.
> The French Skolelinux add on CD have different simplified desktops and
> nice artwork for different grades and user groups. There are a couple
> of people asked to do even more simplification of beautification of the
> desktop with nice pictures and such.
This is nice alright.
> On the technical side we probably have to clean up some dependencies
> that is unwanted. And that will be more easy to do with you helping us
> with a bug report Gavin.
To be honest, I'm not sure what bug report I can write.
> For a while back municipalities i Norway was installing K12LTSP in
> combination with Skolelinux at all their schools. They have changed
> back to Skolelinux based on Sarge with upgraded OpenOffice.org and
> simplified meny with less is more approach. The reason, they say, is
> that they really need stability and slow release cycles.
Perhaps this is correct. We shall see. In my experience, upgrades are
fine as long as you keep the system close to defaults -- avoiding
backports and unofficial packages. I recently had a horrible experience
upgrading Skolelinux. I never quite figured out why but I suspect it had
at least in part to do with a few unsupported backports such as OpenOffice.
> Skolelinux based on Sarge is good enough on the desktop after an update
> of OpenOffice.org to the backported 2.0.3 version, and new Firefox with
> all the necessary media plug-in and Java installed.
as well as the desktop clean-up done by InOut?
> > The difference in quality between the software in Sarge and that
> > in Dapper is substantial. Etch may come out by the end of the year,
> > but if past experience is a guide, much of the software will already
> > be months behind on the day of release and will continue to age.
>
> The schools in Norway used that argument about Skolelinux 1.0. But after
> 2.0 they have experienced that the 12-18 month old version of the
> destkop is not longer a problem. It's new enough, the schools says.
> Also the users get conservative about the destkop. They don't want it
> to change to much to often.
Perhaps you are right but this will only really be clear when Debian-Edu
Etch is released and we know how old sarge is allowed to get.
> The system admins at Norwegian schools have not more than 2-4 hours a
> week to maintain a school network with 50-70 client machines. They
> often have a computer operator at the municipality also, with 2-4 hours
> a week for every school to maintain the system centrally. Upgradeing
> could have complications, and after what they tells me, they don't have
> the time resources to upgrade every year or every sixth month. Every
> secound or third year should be enough. This is much about resources.
> To upgrade every 6 month or 12 month, the schools don't have the
> resources - or they have to cut teaching and use more hours
> on system admin.
Point taken. On the other hand, the longer a system ages, the more likely
a sysadmin will need to resort to backports and other non-standard mods
which are frequently the cause of the upgrade problems.
> The MueKow is the new LTSP project. People from Debian, RedHat and
> Ubuntu has work together fixing and improving a lot of things that did
> not work good enough with the old LTSP. The MueKow LTSP is currently in
> a developing and bugfixing mode. Ubuntu servers as upstream for the
> developers.
Sounds good for all concerned.
> We have also encountered some memory problems:
>
> -- Edubuntu expects 128 MB RAM on every thin client
> -- Skolelinux supported thin clients with 32 MB RAM in version 1.0
That's odd. Edubuntu advertise 48MB minimum.
https://help.ubuntu.com/community/HowToCookEdubuntu/Chapters/HardwareRequirements
Minimal specs
233MHz with 48MB ram. 2MB video ram.
Recommended specs
400Mhz with 128MB ram and PXE boot capabilities.
> When introducing the joint developed MueKow LTSP in Skolelinux 2.0 a lot
> of thin client installations broke bacause the 64 MB RAM limit. A lot
> of schools removed it, and reinstalled LTSP 4.2 (with USB support) and
> swap turned on. Look at this bug report outline the problem:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367606
This is good to know about, thanks. It sounds like it should affect both
edubuntu and debian-edu?
> There also made a guide installing half thin client with Skolelinux
> where hot-plug USB, sound and all other things work as expected. This
> guide needs some improvements, but it get most of the job done:
>
> http://wiki.debian.org/DebianEdu/HowTo/LtspDisklessWorkstation
These have always looked attractive alright. I'd like to get thin clients
moving first and then give these a bash.
> After talking a lot with the maintenance operation that runs > 30
> Skolelinux installations in Norway, they have this list of requirement
> for next Skolelinux:
<snip>
> What more do you want to add on to this list Gavin and others?
At install time the desktop meta-package selection could be separated into
"basic" (one program for each common function) and "kitchen sink" which
would give you the current situation (KOffice & OpenOffice, Konqueror &
Firefox, etc). This would allow one to maintain a standard debian-edu
system without all the redundant packages if one wished.
Properly cleaned up menus. The _standard_ program menu should have two
levels only: a set of categories and the programs within that category
directly underneath. There should be no "debian" menus. I imagine this is
not easily done though as it's really a debian issue, not debian-edu as
such.
Diskless workstations (half-thick) out of the box would be nice.
We are also hoping to use SchoolTool for attendance. The SchoolTool guys
are making debian packages but the attendance module is only in alpha just
now. Perhaps it might be useful to integrate it or a similar package into
debian-edu with LDAP auth, etc.
> Oh. There are a lot of people working with getting Moodle out of the box
> with Skolelinux integrated with CipUX. A debian package is ready for
> testing, and will with 99% probability be a part of Debian Etch.
I've worked with Moodle a fair bit in the past. It's a nice system. I
presume authentication would be done against debian-edu's LDAP system. One
of the issues I would expect would be how to get all of the students onto
the correct course pages (a problem I went over in a 5000 student college).
It's likely that every school's way of doing this would be different, but
it probably comes down to something like
1. Use school management system to export studentid:classid links to CSV
files.
2. Import CSV files into Moodle (and possibly SchoolTool, etc).
I did this work in Griffith College Dublin and we made it available. It's
not terribly pretty, partially because it needed to solve a lot of awkward
problems specific to that college.
http://moodle.gcd.ie/~gavinmc/
I recall thinking at the time that it would be really nice if the school
had an LDAP or SQL database which contained student class enrolments as
well as account details, Moodle, SchoolTool and others could perhaps read
these directly. This is probably quite a complex job though.
Gavin
Reply to: