Diskussion:Linux/Archiv/2013

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Linux/Archiv/2013#Thema 1]]

oder als Weblink zur Verlinkung auVorlage:SSerhalb der Wikipedia

https://de.wikiup.org/wiki/Diskussion:Linux/Archiv/2013#Thema_1

Portal:GNU/Linux

Zur Zeit besteht eine Weiterleitung von Portal:Linux auf Portal:Freie Software. Ich denke aber, dass für Linux alleine schon ein Portal erstellt werden könnte/sollte, wie es auch in der englischen(Portal:Linux) und französischen(Portail:GNU/Linux) Wikipedia der Fall ist. Daher habe ich mal unter Wikipedia:WikiProjekt Portale/Baustelle/Portal:GNU/Linux den Anfang gemacht und würde mich über Interessierte freuen. --Peter Littmann (Diskussion) 23:26, 3. Feb. 2013 (CET)

Wenn-schon, denn-schon müsste es Portal:Linux heissen. Der Zusatz GNU wird in der de-Wikipedia nicht gebraucht, wenn es um Linux geht. --Thomei08 08:48, 4. Feb. 2013 (CET)

Wurde in Wikipedia:WikiProjekt Portale/Baustelle/Portal:Linux geändert. --Peter Littmann (Diskussion) 06:46, 7. Feb. 2013 (CET)

WikiProjekt Linux

Ich möchte mitteilen, dass ich dabei bin das Wikipedia:WikiProjekt Linux zu erstellen und mich über interessierte Teilnehmer freuen würde. --Peter Littmann (Diskussion) 23:47, 6. Feb. 2013 (CET)

"Logo vor 4 Jahren für 3 Monate" am Artikelanfang

Manchmal kann man sich nur an den Kopf fassen, auf was für Ideen die Spielkinder bei Wikipedia kommen. Was soll der Quatsch das Logo "Tuz, ein australischer Beutelteufel mit aufgesetztem Schnabel, der 2009 für drei Monate Tux als Linux-Maskottchen ersetzte" direkt an den Anfang zu sezten, sodass man mit Mobilgeräten erstmal massig scrollen muss, um überhaupt an den Anfang des Artikels zu kommen. Siehe http://de.m.wikipedia.org/wiki/Linux . Und mal ganz ehrlich: abgesehen von ein paar Fanatikern interssiert es keinen normalen Menschen, wenn irgendwann mal für ein paar Wochen das Logo geändert wurde. --94.221.93.33 22:37, 6. Mär. 2013 (CET)

Auch wenn ich gleicher Meinung bin, bitte ich dich - liebe IP - deinen Ton zu mässigen: Anderen vorzuwerfen sie seinen "Spielkinder", "Fanatiker" oder keine "normalen Menschen" halte ich für einer total ungeeignete Vorgehensweise um einem berechtigten Anliegen zum Durchbruch zu verhelfen. Abgesehen davon ist es unanständig und resprektlos. --Thomei08 08:08, 7. Mär. 2013 (CET)

Bin nicht Deiner Ansicht, werde das Logo wieder einbauen, da es ein wichtiger Abschnitt mit wesentlichen Hintergrund war. Allerdings werde ich den Artikel ans ende Setzen --Ulfb (Diskussion) 21:52, 7. Mär. 2013 (CET)

Damit kann ich gut leben. Am Ende kann man das einfügen. Am Anfgang hat es aber sicher nichts verlohren. --Thomei08 07:40, 8. Mär. 2013 (CET)

Ich habe Ihn wie Du evtl. gesehen hast nicht ganz ans Ende gesetzt sondern in's Kapitel Die Bezeichnung GNU Linux, wo der Name und das Logo diskutiert wird. Das ist zwar immer noch weit vorne, aber dann im Kapitel untergebracht - also auf der Mobilen Version nur beim Aufklappen des Kapitels zu sehen --Ulfb (Diskussion) 09:33, 9. Mär. 2013 (CET)

Absatz: Linux als Smartphone- und Tablet-System

der Absatz enthält einen Weblink auf en:wp. Da der anonyme Autor offensichtlich hartnäckig auf diesem Link besteht, bitte ich die Adminschaft um Prüfung. --Pm (Diskussion) 10:26, 28. Jun. 2013 (CEST)

ich habs ge vm't Wikipedia:Vandalismusmeldung#Artikel_Linux.E2.80.8E-- Conan (Nachricht an mich? Bitte hier lang.) 10:32, 28. Jun. 2013 (CEST)

Schon alles korrigiert. Das grössere Problem ist, dass die Firmen Jolla und Canonical sich hier gerne zu breit machten. --Thomei08 10:51, 28. Jun. 2013 (CEST)

Absatz: Distributionen

Zitat: "Da der Linux-Kernel alleine nicht lauffähig bzw. bedienbar wäre, muss man ihn mit Hilfssoftware zusammen verteilen, beispielsweise den GNU core utilities und vielen anderen Anwendungsprogrammen."

Diese Formulierung im aktuellen Artikel täuscht darüber hinweg, daß der freie Linux-Kernel für seinerzeit schon bestehende, vor allem freie Anwendungssoftware, im Besonderen für GNU entwickelt wurde; und folglich nach ihr entstanden ist, soweit ich weiß und in Wikipediaquellen lesen konnte.

Desweiteren ist der Linux-Kernel alleine durchaus lauffähig, nur hätte er dann keinen Zweck ohne Anwendungssoftware, außer jenem, einfach nur zu laufen. Umgekehrt ist wahr: Anwendungsprogramme sind alleine ohne Linux-Kernel bzw. Betriebssystemkern konzeptionell bedingt nicht lauffähig. Ich hoffe, dies vermag geneigten Wikipedia-Autoren bei der Überarbeitung des Artikels erhellend weiterhelfen.

--87.169.230.129 15:23, 28. Jun. 2013 (CEST)

Nee, eine Linux-Kernel allein ist nicht lauffähig, da er auf eine C-Lib angewiesen ist. Diese ist heute meist zusammen mit einem Minimal-System und Treibern (=Modulen) in einem Image (initramfs oder initrd) auf dem Boot-Laufwerk abgelegt. Richtig ist, dass es nicht zwingend die C-Lib von GNU sein muss. Da gibt es grade für Smartphones und im Embedded-Bereich einige Distributionen, die alternativen nutzen. --Thomei08 16:03, 28. Jun. 2013 (CEST)

Zum Hintergrund:

http://www.gnu.org/software/libc/

http://de.wikipedia.org/wiki/GNU/Linux-Namensstreit#Hintergrund

Hallo! Dein Einwand ist interessant und sicherlich richtig. Ich glaube Dir, daß der Linuxkernel auf GNU libc oder ein Äquivalent angwiesen ist. Nach meinem ersten Eindruck würde ich die Bibliothek Gnu C (libc) funktional dem Kernel zuordnen, obwohl es urheber- und lizenzrechtlich zum Gnu-Projekt gehört. Libc könnte man wohl auch als ein Indiz für die enge Verflechtung und funktionale Überschneidung von GNU und Linux-Kernel werten. Historisch und funktional betrachtet ergänzten sich GNU und Linux, trotz Streit und Meinungsverschiedenheit in Grundsatzfragen. Sie kooperierten, weil sie gemeinsam viel mehr erreichen konnten, als jedes Projekt für sich alleine. Diese Kooperation hat den Erfolg von GNU/Linux wesentlich ermöglicht. Beide Projekte bauen auf einander auf. Aus diesem Grund sollte man auch von Gnu/Linux sprechen, wenn man das Gesamtsystem aus GNU-Software und Linux-Kernel meint, oder nur von GNU, wenn man Betriebssysteme aus GPL-Software meint. Anerkennung und Ehre gebührt den Linux-Kernel-Entwicklern, insbesondere Linus Torvalds, nichtdestoweniger. Wie ich erst jetzt erstaunt las, entstand der Kernel aus einer Art spielerischen Experiments. ^o_o^o imho --87.169.230.129 17:31, 28. Jun. 2013 (CEST)

Die Fragestellung des Zusammenspiels zwischen Linux-Kernel und GNU, respektive glibc GNU-C-Bibliothek, hat mir keine Ruhe gelassen und ich habe in einigen Texten gelesen. Eine eindeutige Antwort, ob und wieviel glibc der Kernel für sich selbst braucht, habe ich nicht gefunden. Doch ziemlich eindeutig, weil logisch, ist, daß der Kernel selbst kompiliert wird, bevor er als Binärcode vorliegt, wie die Bibliothek glibc selbst übrigens auch! Glibc ist ein wichtiger Bestandteil des Betriebssystem und stellt wichtigste in der Single Unix Specificition geforderte Funktionen zur Verfügung. Insbesondere sind diese Funktionen von großer Wichtigkeit als Schnittstelle zwischen Anwendungen und Linuxkernel. Also GNU/Linux ist ohne eine Standard-C Bibliothek nicht vorstellbar.

Aber im Wikipediaartikel Linux wird behauptet, daß der Kernel allein ohne GNU Hilfsprogramme nicht lauffähig wäre und verteilt werden müßte. Ob das stimmt, da habe ich doch weiterhin Zweifel. Nach meinem Wissen ist der Kernel Code, der selbständig den direkten Zugriff auf die Hardware steuert und Anwendungsprozesse startet, steuert, beendet und Schnittstellen und Funktionen bereitstellt. Der Kernel braucht einen Bootmanager, um gestartet zu werden, und einen geeigneten Computer, und geeigneten Strom, aber das reicht dann wohl. Dann übernimmt der Kernel das Zepter über den Computer und checkt welche Ressourcen da sind (genannt: autoprobing) und stellt Schnittstellen bereit. Wenn es sich der Kernel so richtig gemütlich auf dem Computer gemacht hat, Hardware erkannt und initialisiert hat, Dateisystem eingebunden und alle Bestandteile des Kernels gelanden sind, dann läuft er, der Kernel - im run level 1. Auf GNU-Bibliotheken musste meines Wissens bis hierhin noch nicht zugegriffen werden. Erst mit dem Initprozess beginnt der Kernel mit seiner Arbeit Hilfs- und Anwendungsoftware Zugriff auf alles Mögliche und Erlaubte zu gewähren, so auch auf wichtigen GNU Bibliotheken. (http://en.tldp.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/bootup.html) Letztlich kann die obige Aussage nur ein echter Kernel-Spezialist verifizieren oder falsifizieren. Oder jemand, der Zeit, Laune und Fähigkeiten hat, mit Linux ohne GNU zu experimentieren.--87.169.230.129 21:11, 28. Jun. 2013 (CEST)

Der Boot-Prozess des Kernels läuft bis zu einer gewissen Stufe ohne Clib. Ab einer gewissen Stufe (bevor der init Prozess geladen wird) greift aber der Kernel selbst auf Funktionen der C-Lib zurück. Das ich nicht's Linux oder GNU spezifisches. Bei BSD oder dem NT-Kernel ist das gänz ähnlich. Der Grund liegt darin, dass diese Kernel alle in C geschrieben sind, man mehr Funktionen nutzen will und man nicht alle Lib's im Kernel einkompilieren möchte, da er sonst zu gross wird. Nur eine kleiner Teil des Linux-Kernels ist in Assembler geschrieben.
Ich denke der Text im Artikel könnte durchaus präziser werden in diesem Bereich. --Thomei08 10:53, 29. Jun. 2013 (CEST)

Das ist falsch. Der Linux-Kernel nutzt die libc nicht. Das kann er auch gar nicht, denn die libc ist darauf ausgelegt, von Anwendungssoftware aufrufe zu bekommen und diese in syscalls des Kernels umzusetzen. Richtig ist, dass der Kernel in C programmiert ist, ja. Das heißt aber noch lange nicht, dass er die libc benutzt. Das ist ja auch keine Bedingung für die Nutzung der Ergebnisse eines C-Compilers. -- Janka (Diskussion) 13:41, 29. Jun. 2013 (CEST)

• So einfach ist das nicht*: strcmp ist im kernel unter kernel/linux/lib/string.c enthalten. Alle teile des kernels die im kernel-space laufen, nutzen die C-Funktionen daraus. strcmp und clib sind aber nicht identisch! Da heutzutage viele teile des kernels im user-space laufen, ist auch die aussage von thomei08 nicht falsch. diese nutzen tatsächlich die clib. Also habe alle ein wenig recht. ;-) (nicht signierter Beitrag von 82.220.1.196 (Diskussion) 09:44, 1. Jul 2013 (CEST))

Das sind keine libc-Funktionen, sondern nachprogrammierte Funktionen mit Aufrufkonventionen im Stile der libc. Ähnlich gelagert: vsprintf(), ABER printk() staff printf() und kmalloc() statt malloc(). -- Janka (Diskussion) 16:24, 1. Jul. 2013 (CEST)

Man kann einen Kernel auch ohne initrd/initramfs und ohne libc booten, das wird im Embedded-Bereich manchmal gemacht (aber wohl selten ohne libc), der Kernel braucht keine libc zum Initialisieren der Hardware oder generell zum Booten. Erst wenn der Init-Prozess gestartet werden soll, wird die libc geladen, mit der init gelinkt wurde. Man kann das leicht ausprobieren, indem man einen Kernel compiled und mit qemu -kernel kernel.img im Emulator bootet. Oder man kopiert ihn in ein Dateisystem und bootet ihn mit grub unter qemu. Hab das zu 2.6er-Zeiten mal irgendwann ausprobiert. Gruß Saule Focke (Diskussion) 21:53, 14. Aug. 2013 (CEST)

Negativ?

"Möchte man Programme nutzen, die für Mac OS X oder Windows, aber nicht für Linux zur Verfügung stehen,..." ist eine irgendwie negativ wertende Formulierung. Tatsächlich ist es doch ein Plus dieses Systems, dass man andere emulieren kann, und das es dann auch noch vernünftig funktioniert (als hinkendes Beispiel läuft bei mir Windows XP unter VirtualBox läuft bei mit nur "1 GB/einem Prozessor" schneller als XP nativ gebootet mit 4GB und 2 Prozessoren). Das kann man also auch besser darstellen.--Mideal (Diskussion) 14:37, 11. Sep. 2013 (CEST)

Das ist ja großartig. Und wie?

Das Beispiel mit VirtualBox hinkt übrigens in der Tat gewaltig, allerdings (auch) noch aus ganz anderen Gründen. Abgesehen davon handelt es sich bei den hier gemeinten Lösungen ja überhaupt nicht um Emulationen i.S. eines vollständigen, anderen Systems, sondern - genauso wie aus der Windows-Perspektive im Falle von Cygwin, den Microsoft Windows Services for UNIX, etc. - um schlichte Implementierungen einer begrenzten User-Mode-Landschaft, ein billiges Surrogat. Und die Fähigkeit dazu ist nun wirklich nichts Linux-spezifisches (geschweige denn etwas, worauf GNU/Linux stolz sein sollte), sondern das kannste so ziemlich überall realisieren. Und du wirst dich auch überall an praktisch exakt den gleichen Limitierungen erfreuen: „In anderen Fällen muss man zu alternativen Anwendungen greifen, die für Linux verfügbar sind.“ Also garantiert ein Plus das sich gewaschen hat, insb. sobald du dann mal fertig bist mit Rumspielen und auf dolle CAD-Software angewiesen bist oder sowas. Ist aber alles bekannt ohne Ende und der Satz da eigentlich längst so neutral wie er nur sein kann und sein sollte. --ZT (Diskussion) 23:11, 23. Sep. 2013 (CEST)

Deine Beispiele passen nicht, denn Cygwin ist keine reine Runtime, sondern auch eine Übersetzungsumgebung. Um ein Unix-Programm mit Cygwin zum laufen zu bringen, müssen dessen Quellen vorliegen und mithilfe des Cygwin-Toolsets "für Cygwin" übersetzt werden. Die "Microsoft Windows Services for UNIX" funktionieren im Prinzip genauso, können allerdings nicht alles, was Cygwin kann.

Wine ist im Gegensatz dazu ein reiner Runtime-Layer, der einer binärkompatible Schnittstelle für MS-Windows-Software anbietet. Dafür muss die Software nicht neu kompiliert werden, sie bekommt im Zweifel nicht einmal mit, dass sie auf einem Linux-System läuft. -- Janka (Diskussion) 15:45, 20. Okt. 2013 (CEST)

Vorfeld Geschichte...

müsste mal überarbeitet werden. Erstens gab's zu dem Entstehungszeit ein freies BSD, welches erst später verklagt wurden ist, zum anderen wurde im Interview von Torvald geäußert, dass er zu dem Zeitpunkt der Entstehung von Linux das freie BSD nicht kannte. Die Äußerung der Rechtsunsicherheit könnte man ebenso Linux benennen, weshalb auch später geklagt wurden ist.--178.24.28.33 11:45, 20. Okt. 2013 (CEST)

Linux Trends

Hallo, ich wünsche mir einen Abschnitt oder Artikel über Linux Trends. Das wäre unter anderem (wie auf Linux.com für 2012 zu lesen):

• 1. Tiny, Cheap PCs
• 2. Linux Preloaded
• 3. Mobile, Cloud, and HPC Dominance
• 4. The Secure Boot Challenge
• 5. GNOME 2's Enduring Appeal
• 6. Commercial Growing Pains
• 7. Linux: The Next Gaming Platform?

7 Top Linux Trends of 2012 --Peter Littmann (Diskussion) 12:33, 4. Dez. 2013 (CET)

und warum soll es in den artikel? was ist daran wiki wert? wünschen kann ich mir viel... -- Conan (Nachricht an mich? Bitte hier lang.) 12:44, 4. Dez. 2013 (CET)

Das kann man gerne in die einzlenen existieren Abschnitte , zum jeweiligen Thema einarbieten. --Thomei08 15:04, 4. Dez. 2013 (CET)

Würde darunter nicht der Gesamtzusammenhang leiden? Wäre es nicht besser dies unter #Entwicklung zu beschreiben und von dort auf die Teilabschnitte zu verweisen? --Peter Littmann (Diskussion) 16:46, 4. Dez. 2013 (CET)

Eine Jahres-Rückblick wird die Linux Foundation wohl wiedereinmal verfassen. Ob 2012 oder 2013 besonders erwähnenswertes Jahre für Linux war, muss die Zukunft erst noch zeigen. Wir sollten in eine Enzyklopädie nicht einzelne Jahren, bei einer über 20-jährigen Geschichte zu ganzen Abschnitten aufblasen. Einige der von der Linux Foundation aufgezählten 7 Top Linux Trends von 2012 sind wohl auch Eintages- respektive Einjahresfliegen. (ev. 2 Jahre) Deshalb sehe ich das ganze eher weniger unter dem Abschnitt "Geschichte". Man könnte aber z.B. Raspberry Pi unter "Weitere Einsatzbereiche" einarbeiten oder die Tendenz zu mehr Linux-Spielen/Spielplattformen in den Abschnitt "Linux auf dem Desktop", usw. Dafür reichen aber je zwei bis drei Sätze. --Thomei08 17:09, 4. Dez. 2013 (CET)

Nun, ich will ja auch nicht jeden Trend beschrieben sehen, aber das große ganze sollte schon im Mittelpunkt stehen. Das, was ich, der ich seit ca. 1994 mit Linux arbeite, unter Geschichte von Linux sehe, kommt mir doch recht dünn vor. Habe dazu folgendes gefunden: Die Geschichte von Linux. --Peter Littmann (Diskussion) 21:13, 4. Dez. 2013 (CET)

Den Geschichte Abschnitt kann man gerne ausbauen. Aber er sollte nicht sein Hauptgewicht auf (die Gegenwart) 2012 (oder 2013) legen, wie die oben genannten 7 Trends. Die Geschichte von Linux ist mehr als 20 Jahre lang. --Thomei08 08:19, 5. Dez. 2013 (CET)