Hallo alle zusammen !
studiere gerade im 2 Semester Informationstechnik und hätte da mal eine
Frage. Ich schaue öfters mal nach Stellenanzeigen und lese dort hin und
wieder "Linux Kenntnisse wünschenswert", "gute Linux Kenntnisse" etc...
Es handelt sich dabei um Stellen aus dem embedded Bereich.
Jetzt frage ich mich allerdings, was mit den sog. Linux Kenntnissen
eigentlich gemeint ist. Klar, letztendlich können mir das nur die
Arbeitgeber beantworten, aber es muss ja eine grobe Richtung geben weil
es dort einfach selbstverständlich aufgelistet ist wie beispielsweise
weitere Fremdsprachenkenntnisse.
Ich würde mich nämlich gerne auch noch etwas mit Linux im embedded
Bereich beschäftigen. Allerdings weiß ich nicht, wo ich da ansetzen soll
(mir fehlt einfach der Weitblick). Habe ich die letzten Wochen mit dem
Gnublin beschäftigt, mal den Kernel kompiliert, einen Webserver drauf
laufen lassen etc... Aber das ist ja sicherlich nicht das, was mit
"Linux Kenntnissen" im Beruf gemeint ist ? Oder doch?
Sicherlich weiß jemand mehr.
Lg
Du kannst Zertifikate für Linux-Kenntnisse erwerben: LPIC-1, LPIC-2 und
LPIC-3. Mit dem 1er hast du etwas auf dem Papier, was Deine
Grundkenntnisse nachweist. Allerdings kosten die Prüfungen Geld. Wenn es
dir wichtig ist, einen schriftlichen Nachweis zu haben, mach den LPIC-1.
Viele Firmen wissen aber gar nicht, was LPI überhaupt ist.
Wenn Du dir Linux-Wissen im Embeddedbereich aneignen willst, kauf Dir
sowas wie ein Pandaboard oder ein Rasperry PI (oder wie das Ding auch
heisst) - wenn es denn geliefert wird - oder ein Beagelboard und spiel
mit allem möglichen rum. Angesagt ist da z.B. Android auf dem
Pandaboard. Abboniere die Pandaboard-Mailingliste und werde schlauer.
Die geringsten Kosten wird wahrscheinlich ein Rasperry PI verursachen.
Aber ob da so angesagte Sachen wie Android drauf laufen, weiss ich
nicht.
In Deine Bewerbung schreibst Du dann rein LPIC-1 und tiefer gehende
embedded Linuxkenntnisse durch Arbeit mit dem Pandaboard und xxxx
Distribution und ... . Dann hast Du schon mal bessere Chancen.
So was bedeutet normalerweise, dass erwartet wird, dass du deinen Knopf
von deinem Arsch unterscheiden kannst, wenn du vor einem Linux sitzt.
Dass du weder in Panik ausbrichst, noch stundenlange Diskussion vom Zaun
brichst, warum der Haufen Scheisse, der Windows genannt wird, so viel
besser ist, oder dass das Leben ohne iDreck nicht lebenswert ist. Dass
du alle Operationen, die man beim täglichen Arbeiten mit einem Computer
so braucht, ausführen kannst, ohne alle fünf Minuten deinen Kollegen mit
Fragen wie "wie kopiere ich eine Datei?" auf die Nerven gehst. Dass du
ein einfaches Shellskript hin bekommst und die gängigsten Programme
kennst und weisst, wie du an Detailinformationen über sie ran kommst.
Dass du das, was du nicht weisst dir in ein paar Sekunden ohne die
Dramaqueen zu spielen schnell selber drauf schaffst.
Ich habe im Job gerade mit einer "Linuxspezialistin" zu tun, die keine
dieser Anforderungen erfüllt. Spass geht anders.
Full ACK an autofill, wobei man natürlich bedenken muss, dass es solche
Leute für jedes Betriebssystem gibt. Mir liefen da bislang aber deutlich
mehr Leute aus dem Windows-Bereich über den Weg.
Damit ist einfach der tägliche Umgang mit dem System gemeint, wenn es um
den Embeddedbereich geht eben noch Entwicklung, Tools ... weniger
LPIC-1/2/3, das sind Adminzertifikate.
Also keine Panik, einfach damit beschäftigen, dann hast du die
geforderten Kenntnisse.
In den Läden wo ich bisher zu tun hatte waren die "Linuxexperten" dort
ziemliche Pfeifen. Genaugenommen waren es Windowsexperten die den
Debianserver hoch und runterfahren konnten, ein paar Kürzel auswendig
drauf hatten aber ansonsten keinen Plan von gar nix. Dazu kam das
überhebliche Gebrabbel das sie in den einschlägigen Foren aufgeschnappt
hatten um ihr mangelhaftes Wissen mit einer Profiaura aufzuschmücken.
Sowas fällt dann halt schnell auf wenn sie auf jemanden stossen der
schon fast 20 Jahre mit Unix arbeitet und entwickelt.
Man muss sich wohl auch nicht unbedingt gleich ins Embedded Linux
stürzen. PC-Linuxe tun es für den Anfang auch, ggf. in einer virtuellen
Maschine, um ein Gespür dafür zu entwickeln. Aber dann eben nicht mit
Ubuntus DAU-Desktop Unity, sondern mit einem Kommandozeilen-System auf
irgendeiner Debian Basis ohne zentralem vereinheitlichem
Konfigurationstool (wie etwa Suses Yast).
A. K. schrieb:> Aber dann eben nicht mit> Ubuntus DAU-Desktop Unity, sondern mit einem Kommandozeilen-System auf> irgendeiner Debian Basis ohne zentralem vereinheitlichem> Konfigurationstool (wie etwa Suses Yast).
Wobei man da fairerweise sagen muss, dass man unter Ubuntu natürlich
auch alles per Kommandozeile machen kann (aptitude usw.).
Er kann also durchaus auch Ubuntu wählen und sich dann tiefer
einarbeiten.
Ubuntu ist meiner Meinung nach für Anfänger besser geeignet - es hakt
weniger bei der Installation.
Die Unity-Oberfläche gefällt mir (nach anfänglich großer Skepsis, gebe
ich zu ;-) mittlerweile richtig gut. Ist aber natürlich Geschmackssache
- dafür hat man unter Linux ja die Auswahl :-)
Also für den OP: mit Ubuntu kann man alles machen, was man auch mit
Debian machen kann (ist ja derselbe Unterbau).
Am besten lernt man den Umgang mit Linux, indem man es wirklich mal
installiert und sich dann "zwingt", damit zu arbeiten.
Und irgendwann öffnet man ein Terminal und schließt es nie wieder ;-)
Zu den Linuxkenntnissen: ich denke auch, dass damit der Umgang gemeint
ist. Man sollte also einen Überblick über das System haben, wissen wo
man Konfigurationsdateien findet und wie man die gängigsten modifiziert,
die Rechtevergabe sollte man kennen, ebenso die wichtigsten Programme
und auch Shell-Befehle. Solche Dinge eben.
Kaum jemand wird von Dir einen Kerneltreiber erwarten (wobei das
wirklich Spaß macht) :-)
Chris D.
Wenn das im Bereich Embedded ist, sollten die Kenntnisse aber schon
etwas über die Shell hinausgehen. Also in etwa: Wie läuft der
Bootvorgang aus einem Flash, typische Bootloader(fallstricke), was muss
wo und warum im Flash liegen, MTD&Co, etc. Je nach System kann man schon
ziemlich viel Zeit damit verbringen, so ein System "from Scratch" zum
Booten zu bekommen. Insb. wenn es eine neue Platform ist...
Das wichtigste in dem Bereich ist Neugier und Spieltrieb. Anlesen und
durchklicken reicht nicht, wenn man das System so gut verstehen will,
dass man bei Problemen auch einen Plan hat, sie zu finden und zu
fixen...
Detrok schrieb:> Jetzt frage ich mich allerdings, was mit den sog. Linux Kenntnissen> eigentlich gemeint ist.
Wenn die Hochschule an der Du studierst etwas taugt, dann werdet Ihr es
früher oder später auch mit einem der vielen Linux- bzw. Unix-Derivate
zu tun bekommen. Zum Beispiel in der Vorlesung über Betriebssysteme,
bzw. in dem Praktikum zur Vorlesung.
Meine Meinung:
- fit auf der Shell sein, kleine Shellskripte schreiben
- Compiler, Linker, make, autoconf bedienen, mit den Fehlermeldungen was
anfangen zu wissen, Pfade fixen, Libs nachinstallieren etc.
- Systemstart verstehen und anpassen: Kernel, initramfs, init-system
(sysv, systemd), initialisieren von Basisdiensten wie z.B.
Netzwerkconfig
Bei all dem gibt es natürlich Unterschiede zwischen den Distributionen,
sowohl im Desktop- als auch im Embedded-Bereich. Schön wäre es
natürlich, wenn Du hier etwas Überblick über die verschiedenen
Möglichkeiten und Varianten hast. Also für Problem x konfigurier ich
mein Netz mit NetworkManager, für y lieber mit dhcpcd und für z lieber
mit ipconfig.
Was dann im Embedded-Bereich eigentlich immer relevant ist, ist der
Umgang mit Crosscompiler-Umgebungen, den Toolchains. Kriegt man oft von
nem Hersteller als riesige Sammlung von Makefiles und Shellskripten. Je
nach Anbieter und Komplexität der Anforderungen kann es etwas dauern bis
Du daraus nen bootbares Demosystem bekommst.
Wenn Du was lernen willst dann nimm keinen Raspberry Pi oder Panda - das
ist von der Community schon viel zu gut dokumentiert und vereinfacht.
Das entspricht kaum der Realität im Arbeitsalltag. Schau Dir z.B. mal
eher die OpenWRT-Teile an und compilier Dir dort die Sachen selber und
mach nen paar Anpassungen. Bei den vielen verschiedenen Plattformen und
Modellen kriegst Du eher nen Gefühl was im Embedded-Bereich so los ist.
Unterschied zwischen Kernel und RFS, Bootloader anpassen, Crosscompiler
aufsetzen, Treiber anpassen/erstellen etc. Wenns dumm läuft ein Support
Package erstellen und dafür Endsupport leisten dürfen.
Das lernt man nicht wenn man nur Ubuntu aufm PC installiert.
> ist ja auch ein schnuckeliger Pinguin...
Das ist ja das tolle am Pinguin-Dünger. Er stinkt zwar manchmal und die
Hände muss man sich auch dreckig machen, aber dafür wächst alles mit
Höchstgeschwindigkeit. ;)
Das Interessante (aber auch das Problem) von Linux ist IMO, dass es
eigentlich auf so ziemlich allem läuft, was so gerade noch eine 32Bit
CPU ist. Es braucht nicht mal eine MMU (uCLinux). Das führt aber zu
einer sehr starken Diversität der Systeme, das fängt schon beim Booten
an.
Bei anwendungsspezifischen Prozessoren gibt es zwar oft etwas, was ein
fertiges Image produziert, aber meistens ist das Buildsystem ziemlich
verhunzt. Das Schönste, was mir bislang untergekommen ist, war ein
STB-Chip von Conexant. Das Ding hat nur alles nur dann richtig
compiliert, wenn man ca. 8 Verzeichnisse unterhalb des Topdirectories
ein Shellscript aufruft...
Zumindest ein solides Verständnis und grundlegene Kenntnisse sollte
wirklich jeder MINT-Student haben. Den Rest kann man sich dann rel.
schnell beibringen und ist vom AG abhängig.
Es gibt aber immer noch Leute, die absolute Berührungsängste haben mit
Betriebssystemen, die nicht von MS kommen bzw. nicht von x.
Dann gibt es Leute, die zu einem Lager gehören wollen (MS, OSx, Debian,
...) und als "Fanboys" bezeichnet werden können - das ist genauso
unprofessionell.
Am Ende sollte man objektiv entscheiden, welche Lösung zu dem Problem am
besten passt.
