Linux in eingebetteten Systemen


Studienarbeit, 2007

30 Seiten, Note: 1,2


Leseprobe


Inhaltsverzeichnis

1 Linux und Open Source
1.1 Die Entstehung von Linux
1.2 Kritik an Linux
1.3 GNU GPL
1.3.1 Copyleft - Freiheiten und Pflichten der GPL
1.3.2 Kritik GPL Version 3

2 Eingebettete Systeme
2.1 Ausgangssituation
2.2 Evaluierung von Linux-Distributionen
2.2.1 OpenWrt
2.2.2 FreeWrt
2.2.3 Entscheidung für FreeWrt
2.3 Evaluierung der Hardware
2.3.1 Asus WL-500g Deluxe
2.3.2 Asus WL-500g Premium
2.3.3 Entscheidung für WL-500g Premium

3 FreeWrt
3.1 Installation
3.2 Konfiguration
3.3 Erweiterung der Speicherressourcen
3.4 Funktionalität und Leistungsfähigkeit

4 Fazit

A Ausgabe des Ringpuffers

B Leistungstest

Abkurzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Linux und Open Source

1.1 Die Entstehung von Linux

Im Jahre 1981 erfolgte die Einführung der mit 8086- und 80286-Prozessoren ausgestatteten IBM-PCs. Diese erste Generation von PCs berührte die UNIX-Welt jedoch kaum, da die großen Hersteller wie AT&T und Sun sie als zu leistungsschwach angesehen haben. Eine Meinung, welche auch von vielen Programmierern vertreten wurde1. Die schnelle Entwicklung in der Informationstechnologie nahm ihren Lauf und so erzielte 1986 der PC in seiner nächsten Generation den Durchbruch am Markt. Ausgestattet war der PC mittlerweile mit einem 80386-Prozessor, der von seiner Leistungsfähigkeit zum Ausführen von Unix geeignet gewesen wäre, allerdings gab es keins dafür. Die großen Unix-Firmen AT&T und Sun sahen die Entwicklung der PCs nunmehr als starke Bedrohung für ihr Geschäft mit Hochleistungsrechnern. Die rechtlichen und wirtschaftlichen Streitigkeiten mit anderen Unix Anbietern wie IBM und Hewlett-Packard hemmten jedoch die Weiterentwicklung von Unix und somit den Prozess, den Anforderungen des Marktes gerecht zu werden. Dadurch schufen sie die Marktlücke für Windows NT. Microsoft nutzte die Gunst der Stunde, in den Unix-Markt einzudringen, den Lizenzstreitigkeiten jedoch mit ihrem eigenen Betriebssystem aus dem Weg zu gehen. Windows NT entstand auf der Basis des Betriebssystems Virtual Memory System (VMS), eines Rivalen von Unix2. Die meisten Programmierer aber, für die Unix zum Standardbetriebssystem geworden war, sahen dem Einzug von Microsoft sehr kritisch entgegen.

Ha rdware was getting cheaper, but Unix was still too expensive. We ” were belatedly becoming aware that the old monopoly of IBM had yielded to a newer monopoly of Microsoft, and Microsoft’s mal-engineered software was rising around us like a tide of sewage3.“

Aufgrund der mangelnden Rechte am Quellcode von Unix war eine Portierung für den PC nicht umsetzbar. Es entwickelte sich eine Nachfrage nach einem freien Unix-System, für das es aber kein wirkliches Angebot gab. 1987 wurde zumindest ein erschwingliches Unix für den PC vorgestellt. Es hörte auf den Namen Mini x und wurde vom amerikanischen Informatik-Professor Andrew Tanenbaum geschrieben. Zusammen mit einem Lehrbuch wurde es für ca. 60 US-Dollar verkauft4. Es war jedoch ein System, welches nur zu Lehrzwecken dienen sollte. Für einen Einsatz als Produktivsystem war es nicht vorgesehen. Auch war der Quellcode von Minix zwar veröffentlicht, aber nicht freigegeben. Der damalige Informatik-Student Linus Torvalds kaufte sich 1991 einen PC und installierte darauf Minix, um das System besser kennenzulernen. Mit einem Modem stellte er eine Verbindung zur Universität her, um dort die Diskussionsforen im Usenet lesen zu können. Da er mit den Fähigkeiten von Mini x zum Aufbau solcher Terminalverbindungen nicht zufrieden war, beschloss er einen eigenen T erminalemulator zu programmieren5. Torvalds reichte dies aber nicht und so entwickelte er sein Programm ständig weiter. Es wurde unabhängig von Mini x, bootete selbstständig und konnte sogar Dateien auf der Festplatte lesen und schreiben. Schließlich wurde ihm klar, dass ein Programm mit solchen Eigenschaften ein Betriebssystem auszeichnete. Seine neu gewonnene Erkenntnis veröffentlichte er direkt im Mini x -Forum6.

Die wohl bedeutendste Eigenschaft für die weitere Entwicklung von Linux war Torvalds Absicht, das Betriebssytem frei anzubieten. Wobei frei nicht nur bedeuten soll, den Quellcode offen zu legen, sondern auch die kostenlose Abgabe und die Möglichkeit, dem Anwender die Freiheit zu geben, den Quellcode seinen eigenen Bedürfnissen anzupassen. Bei der Überlegung für einen Namen seines Programms, kam er auf F rea x. Er kombinierte es aus free für F re e Software, F rea k, weil er sich selbst so sah, und als Abschluss dem X aus Unix. Torvalds bekam von der Universität Helsinki ein öffentlich zugängliches Verzeichnis, unter dem er sein Programm verbreiten konnte. Der zuständige Administrator benannte das Verzeichnis jedoch eigenwillig in Linux um. Linux steht dabei für Linus X-Server. Torvalds akzeptierte die Entscheidung und die Geburtsstunde von Linux war vollbracht7. Bis zur Version 0.11 stand Linux unter einer eigenen Lizenz von Torvalds, welche noch strenger war als die GPL und eine kommerzielle Verbreitung kategorisch ausgeschlossen hat. Ab der Version 0.12 entschloss er sich, Linux unter der GNU GPL freizugeben. Dies war wiederum ein sehr wichtiger Schritt für den zukünftigen Erfolg von Linux, welches weiterhin auch unter GNU/Linux bekannt wurde und sich fortan rasant ausbreitete.

1.2 Kritik an Linux

Die immer größer werdende Linux-Gemeinde traf sich 1992 nach wie vor im Minix- Forum zum Austausch. Das Forum war eigentlich ein Bereich, der für die Entwicklung von Minix genutzt werden sollte. Aufgrund der stetig steigenden Anzahl der Linux-Beiträge wunderte es nicht, dass Minix-Erfinder Andrew Tanenbaum sich herausgefordert fühlte und in seinem bekannt gewordenen Artikel Linu x is obsolete technische Kritik an Linux übte. In einem weiteren Artikel äußerte er seine sozialen Bedenken. Er könne sich nicht die Bildung einer Gemeinschaft freier Entwickler vorstellen, welche, über das Internet und ohne disziplinarische Führungsinstanz, eine produktive Software entwickelt. Außerdem vermöge er es nicht zu verstehen, warum Torvalds die Kontrolle seines selbst geschaffenen Systems überhaupt aus der Hand geben möchte. Dadurch habe schließlich jeder die Möglichkeit, es nach eigenem Belieben weiterzuentwickeln oder gar zu ruinieren8. Torvalds Überzeugung war jedoch klar:

. . . here’s my standing on ”keeping control”, in 2 words (three?): ” I won’t9“.

Technisch kritisiert Tanenbaum insbesondere den monolithischen Kernel10 von Linux. Seiner Ansicht nach sei der monolitische Kernel technisch überholt. Moderne Betriebssystemarchitekturen setzten auf den Microkernel11. Weiterhin kritisierte er die mangelnde Portabilität von Linux. Es sei fest mit der x86-Prozessorarchitektur verbunden, während ein vernünftiges Betriebssystem portabel sein müsse12.

Die mangelnde Portabilität verlor Linux in Laufe der Entwicklung schnell. Die Architektur des Kernels hat sich allerdings bis heute nicht grundlegend geändert. Der Microkernel galt damals als der modernere und flexiblere Ansatz, jedoch unterschätzte man den hohen Kommunikationsaufwand zwischen den Modulen und so setzte er sich aufgrund der dadurch bedingten schlechten Leistungsfähigkeit bis heute nicht durch. Aktuell wird aber wieder darüber diskutiert, ob der Microkernel nicht doch der richtige Ansatz sei und es zu einer Rückkehr kommen könne. Für viele Menschen ist Sicherheit und Zuverlässigkeit in der heutigen Zeit gleichzusetzen mit Leistungsfähigkeit13. In Zukunft sollte man den Anspruch nach einem reinen monolithischen oder reinen Microkernel neu überdenken. Die Firma Apple setzt schon seit Jahren auf einen Hybridkernel und verbindet damit sehr gut die Zuverlässigkeit des Microkernels mit der Leistungsfähigkeit des monolithischen.

1.3 GNU GPL

Bei der Ankündigung des GNU-Projekts im Jahre 1983 versäumte Stallman, sein Verständnis von F reie r Software zu erklären. Durch sein Versprechen, GNU frei an jeden zu geben, der es benötigen kann, legte er den Grundstein für Missverständnisse14.

Daraus entwickelte sich auch die Annahme, freie Software sei gleichzusetzen mit kostenloser Software. Im Jahr darauf erfolgte jedoch die begriffliche Klarstellung in Form des GNU-Manifests15. Das Manifest definiert das Wort Freiheit der Software auf die Art und Weise der Benutzung und nicht auf den Preis. Der Anwender hat das Recht, den Programmcode zu verändern und zu verbreiten. Dies geht für den Anwender mit der Pflicht einher, die Freiheit auch nach der Veränderung weiterhin zu gewährleisten. 1989 wurden diese Rechte und Pflichten in der GNU General Public License (GPL) in ihrer ersten Version festgeschrieben. Seit Juni 2007 existiert die dritte Version.

1.3.1 Copyleft - Freiheiten und Pflichten der GPL

Um ein Programm unter die GPL zu stellen, wird ein Copyright-Vermerk in den Quellcode eingefügt und auf den vollständigen Text der GPL verwiesen. Der Schritt sollte wohl überlegt sein, denn die Entscheidung, den Programmcode unter der GPL freizugeben, kann nicht mehr zurückgenommen werden.

Ziel der GPL ist es, dem Benutzer die folgenden grundsätzlichen Freiheiten einzuräumen16:

- Freiheit 0: Die Freiheit, das Programm auszuführen, für jeden Zweck.
- Freiheit 1: Die Freiheit, zu verstehen wie das Programm arbeitet und es an die eigenen Bedürfnisse anzupassen.
- Freiheit 2: Die Freiheit, das Programm zu vertreiben, um seinen Nächsten zu helfen.
- Freiheit 3: Die Freiheit, das Programm weiterzuentwickeln und die Weiterentwicklung der O¨ ffentlichkeit zur Verfügung zu stellen, damit es jedem zu Gute kommt.

Diese erwähnten Freiheiten hätte man folglich auch dann, wenn ein Programm in keinster Form geschützt wurde. So kam es zum Beispiel in studentischen und wissenschaftlichen Bereichen relativ häufig vor, dass Programme entwickelt und freigegeben wurden, ohne jegliche Auflagen des Entwicklers. Solches Gemeingut bezeichnet man auch als public domain. Dadurch enstehen dem Nutzer keinerlei Pflichten und er kann diese Software nach Belieben verändern und sogar verkaufen. Darin sah Stallman keinen Sinn und suchte deshalb nach einer Lösung, ein Copyright zu erhalten, ohne jedoch die Freiheiten der Benutzer einzuschränken. Mit der GPL drehte Stallman einfach die Verhältnisse um. Was herkömmliche Copyrights verbieten (Kopieren, Verändern, Verbreiten, etc.), erlaubte die GPL. Jedoch wurde dies an eine Bedingung geknüpft: Wird ein Programm verändert und anschließend veröffentlicht und weiterverbreitet, muss diese Veröffentlichung wiederum unter der GPL freigegeben werden17. Diese Methode bezeichnet Stallman als Cop yleft. Es soll eine Anspielung auf die übliche Copyright-Klausel sein. Abschließend sollte man festhalten, dass es sich bei der GPL nicht um einen Vertrag, sondern lediglich um eine Zusicherung des Urheberrechts handelt. Werden Bedingungen nicht eingehalten, so handelt es sich um eine Verletzung des Urheberrechts, das vom jeweiligen Halter eingeklagt werden kann. Der Halter ist dabei der Autor des ursprünglichen Programms. Weiterhin kann nur auf Unterlassung einer unrechtmäßigen Verbreitung geklagt werden. Wird das veränderte Programm privat oder auch innerhalb eines Unternehmens verwendet, so besteht keine Verletzung des Urheberrechts18.

1.3.2 Kritik GPL Version 3

Kritik an der GPL besteht schon so lange wie die GPL selbst. Die hauptsächlichen Streitpunkte sind jedoch genau jene, die von der FSF so beabsichtigt sind und betreffen eher das Prinzip der freien Software. Doch bei der Veröffentlichung der Vorhaben und A¨nderungen in der neuen GPL Version 3 stufen selbst Verfechter der GPL einige Punkte als kritisch ein und blieben gerne bei Version 2. Dabei sollte man bedenken, dass Version 2 bereits im Jahre 1991 entstanden ist. Betrachtet man die Entwicklung der Informationstechnologie der letzten Jahre, ergeben sich demnach auch neue Herausforderungen für die FSF. Vor der Veröffentlichung gab es im wesentlichen drei Kernbereiche, um die gestritten wurde und für die es letztendlich keine gemeinsame Lösung gab: Softwarepatente, Digital Rights Management (DRM) und Lizenzchaos.

Es kommt die Frage auf, ob Softwarepatente überhaupt Thema für eine Softwarelizenz sind. Für manche Entwickler und auch den Linux-Verband offenbar nicht. Nach Ansicht des Verbandes ist der Kampf gegen Softwarepatente eine politische Frage und eine ganz andere Sache als eine im Urheberrecht begründete, vor Gericht durchsetzbare Lizenz. Die FSF sieht dies hingegen anders. Sie argumentiert mit dem fehlenden Nutzen der Freiheiten, welche die GPL dem Nutzer lässt, diese aber durch die Patentansprüche eingeschränkt werden.

[...]


1vgl. GLYN MOODY: Rebel Code: Linux and the Open Source Revolution, Perseus Books, 2002, S.63 [MOO02]

2vgl. GLYN MOODY: Rebel Code: Linux and the Open Source Revolution, Perseus Books, 2002, S.5ff [MOO02]

3ERIC STEVEN RAYMOND: The Art of Unix Programming Addison-Wesley, 2005, Chapter 2 [RAY05]

4vgl. GLYN MOODY: Rebel Code: Linux and the Open Source Revolution. Perseus Books, 2002, S.32ff [MOO02]

5vgl. LINUS TORVALDS and DAVID DIAMOND: Just for Fun, Hanser Fachbuch, 2001, S.59ff [TD01]

6vgl. LINUS TORVALDS: What would you like to see most in Minix?, 1991, http://lwn. net/2001/0823/a/lt-announcement.php3[TOR91]

7vgl. LINUS TORVALDS and DAVID DIAMOND: Just for Fun, Hanser Fachbuch, 2001, S.97 [TD01]

8vgl. ANDREW TANENBAUM: Unhappy campers, 1992, http://www.educ.umu.se/ ~bjorn/mhonarc-files/obsolete/msg00076.html[TAN92b]

9LINUS TORVALDS: Unhappy campers, 1992, http://www.educ.umu.se/~bjorn/ mhonarc-files/obsolete/msg00089.html[TOR92]

10Der monolitische Kernel enthält alle Funktionen zur Speicherund Prozessverwaltung, Treiber für Hardwarekomponenten und das Dateisystem. Er ist dadurch performanter als ein Microkernel, aber auch weitaus anfälliger für fehlerhafte Programmierung.

11Bei einem Microkernel laufen die meisten Funktionen als Module außerhalb des Kernels. Die Aufgabe des Kernels ist es, die Aufrufe dieser Module zu koordinieren. Er ist weniger performant als ein monolithischer Kernel, aber weniger fehleranfällig

12vgl. ANDREW TANENBAUM: Linux ist obsolete, 1992, http://www.educ.umu.se/ ~bjorn/mhonarc-files/obsolete/msg00000.html[TAN92a]

13vgl. HERBERT BOS, ANDREW TANENBAUM, and JORRIT HERDER: Can We Make Operating Systems Reliable and Secure?, Vrije Universiteit, Amsterdam, 2006. IEEE Computer, vol. 39, no. 5, S. 44-51, Mai 2006;[BTH06]

14vgl. RICHARD MATTHEW STALLMAN: New Unix Implementation, 1983, http://www. gnu.org/gnu/initial-announcement.html[STA83]

15vgl. RICHARD MATTHEW STALLMAN: The GNU Manifesto, 1984, http://www.gnu. org/gnu/manifesto.html[STA84]

16vgl. FREE SOFTWARE FOUNDATION: The F ree Software Definition, 1996, http://www. gnu.org/philosophy/free-sw.html[FOU96]

17 vgl. FREE SOFTWARE FOUNDATION: GNU General Public License, 2007, http://www. gnu.org/licenses/gpl-3.0.html[FOU07]

18 vgl. BUNDESMINISTERIUM DER JUSTIZ: Gesetz u ¨ b er Urheberrecht und verwandte Schutzrechte, 2003, http://www.gesetze-im-internet.de/urhg/index.html[JUS02]

Ende der Leseprobe aus 30 Seiten

Details

Titel
Linux in eingebetteten Systemen
Hochschule
Duale Hochschule Baden-Württemberg Mannheim, früher: Berufsakademie Mannheim
Veranstaltung
Systementwicklung
Note
1,2
Autor
Jahr
2007
Seiten
30
Katalognummer
V120056
ISBN (eBook)
9783640240432
ISBN (Buch)
9783640248858
Dateigröße
510 KB
Sprache
Deutsch
Schlagworte
Linux, Systemen, Systementwicklung
Arbeit zitieren
Dipl.Wirtsch.Inform. (BA) Frank Hemer (Autor:in), 2007, Linux in eingebetteten Systemen, München, GRIN Verlag, https://www.grin.com/document/120056

Kommentare

  • Noch keine Kommentare.
Blick ins Buch
Titel: Linux in eingebetteten Systemen



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden