Killer feature for big Education deployments: kiosk returns

Most of the people I’ve met that participate in taking the decisions in IT related to Education in public administrations related are not technicians. Many people around libre software tend to think that the decision to go for Windows or Linux based desktops (GNOME  or KDE) has a lot to do with technical, usability or the look & feel features. Throughout the years, we have concentrate a lot is these aspects hoping that winning the any of those wars, we would suceed in being chosen as the default desktop in education.

During the decision process made by those people, when considering KDE and GNOME as default desktop compared to Windows, three considerations play on our side:
  • TCO cost
  • Availability of many useful applications within a classroom.
  • Computer’s lifecycle increase.
Thanks to our effort, most of the good applications we have in Linux plattforms, are already availiable for Windows. KDE has done a huge and succesful effort in this area (KDE for Windows project).

The TCO cost is a relevant one, but it is not the most important one. The experience tell us that it is the mainteinance and support the biggest piece of the cake in the medium term.

That cost has basically 3 sources:

  1. Communication (connectivity)
  2. Hardware
  3. Software
If we ask any user support department from a IT Education oriented organization, they will tell you that most of the software support queries comes from:

  1. Users that do not know how to use the software
  2. Teachers that report that the software do not work properly because an unexpected action from a student. 

The second queries are fatal ones since they are more difficult and more expensive, to solve.

When talkign about migrating schools from Windows to Linux based desktops, one of the major features KDE had to offer in the past was our ability to port in a more scalable and cheaper way many of the features implementd in schools related to user profiles and desktop lockdown offered with Windows desktop + Active Directory. We could do that because of Kiosk.

During the KDE Edu Sprint public event that is took place yesterday in Bilbao, two people from two different Edu projects, one from Portugal and another one from Spain, pointed out the strong effort that is taking to them porting what they usually did in KDE3 with Kiosk to KDE4. In fact, they both agreed that support queries will increase due to unexpected actions done by students with the new software (KDE4).

It is easy to think that for big deployments, not having fully implemented kiosk is a major obstacle for switching from KDE3 to KDE4. Without kiosk mode working properly, we cannot compete with the Adctive Directory + Windows desktop in most of the features related with user profiles and lockdown of unusable features either.

From my point of view, related to Education, our priority should be to have a  fully inplementation of kiosk mode for KDE4. If we want to beat Windows in Education, we have to think about the maintenance cost of having a huge number of desktops to take care of. Kiosk is in these situations is the best feature we can offer.

We have talked about this during the KDE Edu Sprint. Alex Fiestas  is already doing some previous work in order to know what is missing and what is the effort needed to bring kiosk mode back in KDE 4.

I cannot think on a better way of having in the near future more new deployments in schools based on KDE 4, and the ones we already have switching smoothly to KDE 4, than giving them a killer feature that has a direct impact in medium term costs. Kiosk was our strongest feature in this area. It is worth it to have it back, even better if we can.

Big deployments of desktops and Kiosk Mode

Another item included in Edu-day discussions was related of the importance of the kiosk mode. I’ve written this while travellling and haven’t checked grammatical errors. I’ll do it the following days. But today it has been published info about the aKademy 2007 and I think it is the right day to publish this. Sorry for my english.

The kiosk mode is a key feature in KDE for big deployment because many reasons. This post go through two of them:

1.- Reduce the amount of data to transmit for updating desktops.

2.- Allows a systematic method of setting profiles for users so costs are reduced.

All the features of the desktop and the kde apps can be controlled in one directory, in a few number of .txt files under /usr directory. This means that, by changing a really few light archives, we can control desktop configurations and set different profiles with heavy customisation, that the user cannot change. This is basically what kiosk mode allows us to do. When we talk about thousands of computer with different profiles, like in mEDUXa (35,000 with 5 profiles each), this is a big issue.

When we talk about homogeneous networks or deployments, we do not refer to the network itself, specially the bandwith. This usually depends on geographical factors hard to control, so its heterogeneous. Traditionally this has been a huge problem in many places. The Canary Islands are no exception. Not just because they are seven islands in the middle of the Atlantic sea, but because they are volcanic, so there are many mountains.

Lets resolve a simple math problem. If I have to change a configuration in a desktop that is placed in user space, in a .txt file of 2 KB for example, it means that, if I have 10,000 users in 100 schools (100 users per school), I should send to school servers 2×100=200 KB through my network, and then make an update of 2×100= 200 KB in each school (if some users are able to log in with different profiles, the number grows) through its LAN. That is a total of 200×100=20,000 KB, something around 19.5 MB.

If the configuration change means 3 archives of 30 KB each, placed on the user space, and we have 1100 schools, 300,000 users and 5 profiles, you add the problem of bandwith limitations (we have ADSL of different bandwith and many satellite connections in many schools) to this equation, and then, the enormous cost of sending technicians from one island to another one… sleeping well gets harder. Kiosk mode makes a difference.

First of all, kiosk mode is set by text files, really light. By configuring features in a centraliced way, you only have to make one change (under /usr) per profile in a machine (if it is set locally), and not per user. This is a huge reduction on the amount of data that needs to be updated, so the control of that process and the possible point of failure are drastically reduced.

By setting the features configurations under /usr/local/share, we avoid user from changing them.

Lets take a look at firefox, for example. If you use a proxy to navigate, this browser doesn’t let you place that feature in the system space, so you cannot block it from being manipulated by users. Since the browser is used almost every day many times in a computer lab of every school, we can say being optimistic, that at least, once each two days the teacher is going to have a problem. He is going to tell the school coordinator about it so he/she will send the report to the centralised support department, that a user cannot navigate, lets say, once each two weeks. The technician will take about 5 minutes to figure out if it is a network problem by checking it, connect to the machine by ssh, check the browser, go to the user profile and verify the proxy configuration. 5 minutes a week per school means 5×1100=5500 minutes, that is 12 working days (8 hours each). If the cost of an hour is 30 €, for example, that means about 2700 € per every two weeks, 5400 €/month. If the computer lab is used 8 months per scholar year, not following the kiosk mode in this case cost about…. 43,000 €

Of course you need to set a solution for that before the disaster takes place. So you can make all kinds of hacks to solve a structural problem of the app or go directly and substitute it, if there is any available, by another one with the same features, that can be integrated in kiosk mode (KDE app). If there is any, you pay somebody to fix it (hopefully the developer) or…..kill yourself. Or even worse get killed by teachers or students because you don’t solve the problem.

Of course this is not a real problem. They can be even worse. But it shows clearly how important is for big deployments that all desktop and apps features can be configured through the kiosk mode and why it is such a relevant argument for electing KDE. This can help people understand why windows has such a huge cost of support per machineper year.

But kiosk mode is not just a feature, it is an agreement of a community to follow some development rules that allow other people to customice the desktop and apps in a systematic way, simplifying the action of setting and changing configurations and avoiding failures because of users actions. It is even more, it makes possible to extend the concept of scalability to the desktop, by allowing to offer different profiles in the same machine without multiplying the points of failure in a linear way. This means that in the future we can achieve the idea of a student using different profiles during his scholar life but having the same user space, saving all the data and customisations he has made in school and taking them home. Only with kiosk mode is possible to think in a profile for the math class, another one for chemistry, etc. for each student. Each of them with requirements established by teachers, implemented centrally by technicians and deployed in a short period of time.

So I have two important suggestions for KDE developers.

1.- Make all your features configurable using kiosk mode.

2.- Document them. So projects like mEDUXa can apply them and users can take advantage of them.