As you all know, a discussion has taken place concerning the broadband requirements for LTSP (Linux Terminal Server Project). Especially Roger Larsen in «www.fronter.com» has worked on this since 23. December 2002. Although LTSP is a big success in the Norwegian Schools today, Utdanningsetaten (the municipal department of education) in Oslo also want to add some more functionality to it. Utdannings og forskningsdepartementet (the Norwegian Ministry of Education and Research) expects the benefits of the solutions to be available for educational use all over Norway. SLX Debian Labs meets those requirements by using a user friendly license (GPL) on software and by documentations of their solutions. «It is considered highly important to develop a good practice that is usable also in all the Norwegian schools1» says the Ministry concerning the continuation of the Skolelinux Project, 24. September 2002. The next section documents their expectations.
Utdanningsetaten in Oslo has, through their project called InnsIKT (insight), a desire to use servers, centrally placed in a service center. As of today they have a non-optimal solution were each school has one or two windows servers on their own. On these servers the pupils have their own storage Area for workstations, some nett services, authentication through MS active Directory and some more. This is due to the fact that the bandwidth of those Schools lies between 2 and 8 Mbps. Increasing the bandwidth would easily exceed the price of maintaining all the school computers in Oslo. To keep as much as possible from the InnsIKT architecture and to reuse hardware, we want to decrease the bandwidth requirements between the thin clients and the Skolelinux application server, also known as the thin client server. This can be done with NX from NoMachine, also known as FreeNX, or with Lessdisks. It is also possible to use a combination of these two.
This is part of the instructions coming directly from the city council, who asked SLX Debian Labs to put in an application for the project2. The representative from the city council (byråden) in Oslo has taken over the case, and it was then sent to the administration, in this case Utdanningsetaten in Oslo. The city council has taken the following decision on the 21. may 20033:
«The committee asks the city council to incite more schools into using Linux. The representative from the city council should use the experiences form for instance Bjerke Videregående skole (Bjerke high school) and Holmlia ungdomsskole (Holmlia secondary school) as an inspiration for others to start using Linux as their computer system.»
Siemens Business Solution and Utdanningsetaten (SBS) i Oslo expects to find someone the schools may contact for the receiving of security upgrades, maintenance and new versions of Skolelinux. SBS uses the same arguments as for instance the Norwegian Ministry of Education and Research; the latter states: «One has to ensure that the ability of deliverance will continue, even if some participants should change life conditions», and further: «the most important thing for the Ministry is that they can recommend the organizational part of Skolelinux.4»
The Ministry wants someone to do the administration, someone that can answer requests and be in charge. They may employ new employees and be there for the future too. One also should ensure a physical and organizational unity, an Organization that will maintain Skolelinux for the next five years.
The economical expectations can be found in the project report from SLX Debian Labs that was written on the request from the city council in Oslo5. The Skolelinux project shows that the maintenance of the system would cost 533 NOK per user, reduced to 360 NOK when the system is fully deploied. The alternative Windows solution today costs about 1000 NOK per user, reduced to 750 NOK when it is fully developed, says the computer director Bjørn Marthinsen in Utdanningsetaten in Oslo6. Following the budget proposition of Utdanningsetaten for the InnsIKT project from 2003 it would, yearly, cost more than 211 millions to maintain a fully developed InnsIKT solution based on Windows. By using the calculations given to the media by Utdanningsetaten this means more than 50 millions in external maintenance costs. SLX Debian Labs has proved that this can be reduced to 25 millions by using Skolelinux. The savings probably could be even higher by doing changes concerning the thin clients: the need for local bandwidth could be reduced, and the thin clients processors could be turned to account as half thick clients.
LTSP in Skolelinux has to be maintained in accordance to the Debian security policy7. We have not reached this goal as of today, even if the security team in Skolelinux has the required knowledge8. Our present solution has been to repack Red Hat rpm-packages and adapt them to Skolelinux. We intend to use Debian Packages. Until now the repacking has been done by Ragnar Wisløff. Also Linpros Rune Skillingstad, Finn Arne Johansen and Petter Reinholdtsen has made valuable free contributions (I have surely forgotten someone). http://www.ltsp.org/ltsp-4.1.html.
The need for bandwidth can be reduced9. Some Municipalities in Norway want to place the application server centrally rather than getting the full effect of the hardware by using thin client servers as «black boxes». In the same way as with Citrix this reduces the possibility of using heavy programs built on Flash and Java on the clients. The NX-technology10 is supported both by the KDE environment and in other ways.
Half thick clients can be maximized and then support heavy applications like Java, Micromedia Flash and video. This can be done through LTSP or with Lessdisks. Jonas Smedegaard <dr(at)jones.dk> – and others – are working with the latter.11
Alternatives |
the 0 alt. |
1. alt. |
2. alt. |
3. alt. |
4. alt. |
---|---|---|---|---|---|
X-handling |
LTSP as today |
LTSP + NX |
Half thick LTSP |
Lessdisks |
Lessdisks + NX |
Advantage |
Ready for web based exams with flash |
More centralization |
Can run Flash, Java and Multimedia |
Can run Flash, Java and Multimedia |
Can run Flash, Java and Multimedia |
Disadvantage |
High bandwidth |
Flash runs more slowly |
Higher bandwidth |
Average bandwidth |
Untried technology |
Server |
Local black box |
Central/local |
Local black box |
«Small» local black box + central |
«Small» local black box + central |
Bandwidth |
~ 2 Mbps |
~ 20–500 Kbps |
~ 2–10 Mbps |
~ 100k – 10 Mbps (~2 Mbps as thin client) |
~20k – 10 Mbps |
CPU |
> 90 MHz |
> 133 MHz |
> 450 MHz |
> 450 MHz (133 MHz as thin client) |
> 450 MHz |
Memory |
> 16 MB |
> 32 MB |
> 64 MB |
32-64 MB |
> 64 MB |
Adaptations |
Make a Debian package |
Integrate NX, configure for SLX and make a Debian package |
Integrate the application, configure for SLX and Make a Debian package |
Adapt Lessdisks, configure for SLX and make a Debian package |
Adapt Lessdisks, integrate NX, configure for SLX and make a Debian package |
Development time (consideration – see explanation) |
250h (packaging and maintenance for one year) |
250h (development) + 450h (packaging and maintenance for one year)=700h |
250h (development) + 450h (packaging and maintenance for one year)=700h |
250h + 450h + 450h = 1150h |
250h + 450h + 450h + 450h = 1550h |
About «consideration»: A consideration is here meant to be a judgment based solely on personal assumptions or considerations, and not to be very accurate. This is in contrast to «estimate», which is here meant to be made by a calculation of probability.
About «estimate»: When translating for instance OpenOffice.org (OOo) we have calculations based on our former experiences, made available through weekly reports from the translators on their work. And because we have been translating OOo since summer 2002, we can estimate what remains to be done by knowing the amount of remaining strings.
About our judgments for LTSP (the 0 alt.): 250 hours makes 6 weeks. One not only has to build a Debian package, but also use time to repack and test the system for new versions. If a big organization as the Municipality of Oslo is to use this solution, then it has to be maintained when new security fixes appears, new kernels and X-servers etc. In other words: we are here talking about both adaptations and maintenance. Perhaps 250 hours a year is too much? We will know when we are able to make a proper estimate, not just a simple consideration.
Our thoughts behind the judgments for Lessdisks (alt. 3) are the following: It takes 250 hours to make a package for this solution. 450 hours will be necessary to test that it is working properly and 100%. 450 hours will be needed to maintain security patches and new versions. All in all this makes 350 hours more than considered for the work only. Finn-Arne considers 800 hours for the making of a run-ready version of Lessdisks. And then it also has to be maintained.
How much time have you already used on your contribution? You have to count all your working time and then multiply this with two (time used x 2 = estimated use of time). System developers are notoriously underestimating their use of time, by a factor of 3 to 5.
You have to add the same amount used for adaption once more to account for the testing time.
You have to add this amount of time once more to account for packaging and documentation.
Be prepared that between 1/4 and 1/3 of your working time will be used for administration, management and accidental circumstances.
We are not done yet: 80% of the computer costs are used on maintenance; also add this to your calculations.
Short resume, including how to estimate your work time on development: Take what you thing you have done and multiply it by 2. Multiply your answer with pi (π). <URL: http://en.wikipedia.org/wiki/Pi>.
When you have developed the solution, you have to use 1/3 of your total development time on new versions of the system. You have everything except the new code. You do not have to build up the same bureaucracy once more, reuse your former tests etc. Everything is saved in CVS.
You have to add the time it takes to build a new Debian package, including security fixes. You have to test this. If you have former tests, reuse them. Expect yourself to repack the system 3-4 times a year (because of security fixes and new kernels for LTSP/Lessdisks).
You have to handle feedback from your costumers; this will often cost you between 1/4 and 1/3 of your total working time.
Sources:
Project Estimation in the Norwegian Software Industry – A Summary http://www.simula.no/publication_one.php?publication_id=720
National Science Foundation (USA) Faster, Better, Cheaper: Open-Source Practices May Help Improve Software Engineering http://www.nsf.gov/od/lpa/news/03/pr03132.htm
The Development of Interactive Systems: Bridging the Gaps Between Developers and Users http://www.ics.uci.edu/~grudin/Papers/IEEE91/IEEE91.html
Report on the translation of OpenOffice.org http://developer.skolelinux.no/rapporter/ooo_ks_finans.pdf
The LTSP solution being used today is, relatively speaking, easy to maintain – if you modify the demands concerning Debian packaging. Today this is done on a voluntary basis by Ragnar Wisløff and Finn-Arne Johansen. LTSP 4.1 is part of the test version of Skolelinux sarge (based on Debian testing). Ragnar has made binary files of this, compressed it as a tar archive and packed it as Debian files; Finn-Arne has adapted the system for starting direct from a CD. Jonas Smedegaard <dr(at)jones.dk> stresses the importance of maintenance:
«Active work is being done to adjust the discrepancies between Debian and Skolelinux. (...) An example for such a discrepancy is the use of LTSP, which in its current state does not meet the Debian Policy requirements. It may later be possible to make packages that meet this Policy. As an alternative, Skolelinux could consider using Lessdisks, or another thin client system that is included in Debian.
How fast can security holes be repaired – and how big is the overall possibility that someone discovers them? As far as I know, using LTSP it is pretty complicated to change the Linux kernel, and even harder to change a X-library. In Lessdisks all(!) the binary code is officially being maintained by Debian – the X-libraries are upheld by Branden Robinson, and the Linux Kernel can be updated as fast as on your «thick» work station or server.»
I have asked Johnny, daily manager for InOut Data, for an open meeting concerning these matters for the following reasons:
To use students for such a project can make it all derail. It is easier to make a prototype than to make working code when using system critical solutions.
Some Debian maintainers are better at maintaining their packages and making patches than in making new improvements. If for instance you have to integrate the NX-technology in the X-protocol (and thereby reducing the bandwidth for standard applications from 2 Mbps to 20-40 Kbps), then this may demand an even higher developing competence.
I asked Jim McQuillan <jam(at)Ltsp.org> (the father of LTSP) if he could be able to help us with estimates and strategy. He integrated our question in his presentation on GUADEC 2004 in Kristiansand (Norway).
Jonas Smedegaard <dr(at)jones.dk> has sent us his answer on our question concerning Lessdisks and the need for maintenance, be it Lessdisks or LTSP.12
The main point is to (1) ensure lower bandwidth. The second (2) to ensure a stable and well done maintenance of the solution by having security updates and new versions as maintainable Debian packages. It therefore has to be decided on the strategies for optimizing the thin clients. This solution has to be sent upstream both to the LTSP project / Lessdisks and to Debian.
A good overview of the requirements, including estimates (not just considerations as of 29. September 2004).
A good description of what to expect from the delivery, for instance:
Code in CVS upstream to LTSP and Lessdisks
Maintained Debian packages
Documentation
Reports of the testing and delivering
Overview over student projects with relevance to this subject:
http://developer.skolelinux.no/info/studentprosjekter/studentprosjekter.html
http://developer.skolelinux.no/info/studentgrupper/2004_kandidater.txt
First some background information before we are going to look into the financing of an improved thin client solution. The Ministry considers it unfair that the only way of financing should be free contributions. For many parts of the work in a development project it may be difficult to get people who will contribute for free. On a meeting in the department UNINET was mentioned as one example. They are organized as a limited company and gets their income from user organizations, says Odd Asbjørn Halseth. All their income comes from the government, but they are an independent organization. Until now, all works been done in Skolelinux are financed private, through SLX Debian Labs or been done on free contributions.
The SLX Debian Labs was founded to meet the demands from the Ministry for a stable organization for at least five years, and to manage the maintenance of central Debian-edu components for school owners expecting a safe and solid maintenance of the system from payed employees. The foundation and role of SLX Debian Labs is, through a meeting on stable organization 29. April 2003, bound to all the different parts of the Skolelinux organization.13
These improvements are wanted by Fronter, represented by Roger Larsen, InOut, represented by their manager Tor Johnny Flaa, and by Utdanningsetaten in Oslo. Knut Yrvin has told them, that everything is possible, and that our intentions are exactly the same. But we have to analyze the extent of this work and find the best approach to get it done. The approach is important because we want to prevent future licensing costs and unnecessary maintenance responsibility. Nothing is cleared concerning who should do the job or maintain it. Considering the very good contact Linux Labs <firmapost(at)linuxlabs.no> has to Jim McQuillan, this could save the amount of time used on the project by reducing the transaction costs on achieving the solution. This would fit the expectations from the department; Skolelinux could get the people to do this and ensure lasting solutions for the future.
Knut Yrvin from SLX and Tor Johnny Flaa <johnny(at)inout.no> from InOut will call for a meeting on the mentioned subject. It is important to investigate this on a professional level before deciding to use between 250 and 1500 hours (maintenance not included) on the development of new functionality for the thin clients in Skolelinux.
A copy of this is sent to the Skolelinux list, also asking for comments or improvements in reference to the dialog with Utdanningsetaten in Oslo. Before this both Vidar Bakke (SLX Debian Labs) and Erlend Reitan (InOut) were informed. Roger Larsen <roger.larsen(at)fronter.com> (Fronter) said «go for it, but not later than on NKUL 2004», so all the managers are informed. Both Ragnar Wisløff and Finn-Arne Johansen have received a copy of a summary from conversations with Tor Johnny Flaa from InOut in September.
1. Expectations on the further development of Skolelinux: http://developer.skolelinux.no/info/prosjektet/referater/viderefoering_av_skolelinux.txt
2. A application from 20 schools on the demand of the city council: http://developer.skolelinux.no/driftskonsepter/utsikt.html
3. Summary from a meeting with the Finanskomite (committee of finances) 21. may 2003: http://www.sak.oslo.kommune.no/dok/Bys/2003/FKOM/2003004533-1.htm
4. Summary from a meeting with UFD, UNINETT ABC 15. November 2002: http://developer.skolelinux.no/info/prosjektet/referater/ref_ufd_20021115.txt
5. A application from 20 schools on the demand of the city council: http://developer.skolelinux.no/driftskonsepter/utsikt.html
6. A report on the maintenance costs in the schools of Oslo, from IT-avisen.biz: http://www.itavisen.biz/showArticle.php?articleId=9945
7. Securing Debian Manual http://www.debian.org/doc/user-manuals#securing
8. Security in Skolelinux http://www.skolelinux.no/security/
9. A short description of the thin client solution used by the IT-manager in Nittedal: http://developer.skolelinux.no/brev/20040622_tynnklientytelse_nittedal.txt
10. About the integration of FreeNX in KDE: http://wiki.kde.org/tiki-index.php?page=NX%2FFreeNX+integration+into+KDE
11. The answer from Jonas Smedegaard <dr(at)jones.dk>: https://init.linpro.no/pipermail/skolelinux.no/linuxiskolen/2004-September/015614.html
12. LTSP-bug in Debian (how to package): http://bugs.debian.org/163000
13. The founding of SLX Debian Labs http://developer.skolelinux.no/info/prosjektet/referater/troverdig_org.txt