[achilleus]

Hallo zusammen,


schon jemand Erfahrungen mit der Ubuntu Bash in der neusten Insider Build gemacht?

Konnte diese Problemlos installieren, sie läuft auch, aber ich bekomme keine Internet/Netzwerk Verbindung von der Bash aus:



Angeblich gibt es keine Netzwerkschnittstelle in der Bash. Finde leider auch gerade keine Lösung für mein Problem.
Danke!

[Sturmovik]

Das Linux-Subsystem hat keine Möglichkeit, Netzwerksockets zu öffnen. Soviel zu dem halbherzigen Versuch Microsofts, mal ne ordentliche Shell einzubauen.

Wenn du die Bash (und alle anderen Linux-Programme) richtig nutzen willst, nimm Linux.

[achilleus]

Zitat (Sturmovik: 23. April 2016 - 18:31)

Das Linux-Subsystem hat keine Möglichkeit, Netzwerksockets zu öffnen. Soviel zu dem halbherzigen Versuch Microsofts, mal ne ordentliche Shell einzubauen.

Wenn du die Bash (und alle anderen Linux-Programme) richtig nutzen willst, nimm Linux.

Es soll wohl häufiger noch Probleme mit dem Netzwerk im Subsystem geben, also abwarten.

Und zu dem abwertendem Teil der Antwort: Ich freue mich über die Möglichkeiten, die die Einbindung des Kernels direkt in ein Windows System bringt. Wenn dir das nicht gefällt denn beachte diese Themen einfach nicht und behalte deine Gedanken bei dir - damit wäre allen geholfen. (Nutze Linux normal auch täglich..)

[Sturmovik]

Zitat (achilleus: 23. April 2016 - 18:48)

Es soll wohl häufiger noch Probleme mit dem Netzwerk im Subsystem geben, also abwarten.

Schaumermal...

Zitat

Ich freue mich über die Möglichkeiten, die die Einbindung des Kernels direkt in ein Windows System bringt.

Wer hat dir denn erzählt, dass der Linux-Kernel in Windows eingebunden würde?
Die Syscalls aus *nixioden Programmen werden übersetzt und durch den NT-Kernel ausgeführt. Und daher rührt auch das Problem, dass die im Linux-Subsystem laufenden Programme nicht an die Hardware rankommen => kein Xserver (gut, brauch man eher weniger), keine Netzwerksockets und weitere Einschränkungen.

Zitat

Wenn dir das nicht gefällt denn beachte diese Themen einfach nicht und behalte deine Gedanken bei dir - damit wäre allen geholfen. (Nutze Linux normal auch täglich..)

Im Gegenteil, die Grundidee gefällt mir sehr. Nur die halbherzige Umsetzung und die Begrenzung auf den Desktop nicht.

[RalphS]

Huh?

Gab es da Updates? Hatte da bei mir überhaupt keine Probleme. Mußte stattdessen das Subsystem reinitialisieren, weil ich mutigerweise die "Ubuntu-Distribution" per dist-upgrade erneuert hatte und das... nicht ganz so gut endete.

- Anyway, zumindest mit Centrino-class WLAN nicht die geringsten Probleme.

---

Edit; grad nochmal geschaut. Windows läßt einfach den Zugriff auf Raw Sockets nicht zu. Wenn ich mich recht entsinne, gabs doch eben dazu jede Menge Geschrei vor ein paar Jahren, WEIL sowas ging? Jedenfalls, es sieht so aus als ob "reguläre" Applikationen funktionieren - also solche, die nicht die *socket() Funktionen verwenden. Weswegen apt-get(8) & Co funktionieren - links(1) auch -- und zB nslookup(1) oder host(1) aber nicht. Wäre jetzt auch die Frage, ob nicht unter Umständen einfach die installierte Firewall querschießt; da müßte man ggf nachsehen.

Dieser Beitrag wurde von RalphS bearbeitet: 23. April 2016 - 19:16

[IXS]

Ich schätze mal, dass die BASH erst dann richtig funktioniert, wenn die typischen Linux Sicherheitslücken beseitigt sind. Das wäre schließlich eine Katastrophe , wenn Viren die Chance bekämen, sich wie unter Linux zu verbreiten. Weil, unter Windows würde das gemacht, was unter Linux "noch" nicht gemacht wird, weil man das System pushen will. Aber ein Windows, das so blank wie Linux zieht... nun, man weiß ja, wie XP so in den ersten Jahren war... Eine Virenhure ...

[RalphS]

1. Linux ist nicht bash.
2. bash hat nix mit Linux zu tun, außer daß sie da zufällig drauf läuft.
3. bash hat mit Windows noch viel weniger zu tun (weswegen natürlich Microsofts Gefasel von "Windows Bash" oder sowas komplett albern ist).
4. Linux-on-Windows hat sehr viel weniger Rechte als Linux-on-Baremetal -- allein deswegen, weil Linux-on-Windows im Benutzerkontext des angemeldeten Benutzers läuft oder, wenn wir ganz genau sein wollen, im Benutzerkontext der *Windows-Anwendung* namens "bash.exe", welche sich in %SYSTEMROOT%\System32 befindet und welche *leider* von Microsoft diesen Dateinamen bekommen hat; denn
5. bash.exe hat mit bash auch nichts zu tun. bash.exe ist einfach ein Bootstrapper für Linux-on-Windows. Ganz ähnlich wie bei SUA seinerzeit (und die Metro Apps dieser Tage) sind nämlich die unixoiden Applikationen unter Windows nicht nativ ausführbar, sondern bedürfen einer Laufzeitumgebung, die zumindest momentan noch nicht implizit geladen wird. "bash.exe" könnte genausogut "UoW.exe" (von ubuntu-on-Windows, laut Microsoft) heißen und es würde genau dasselbe passieren, die Laufzeit würde gestartet und bash als eingetragene Shell gestartet. Insbesondere: wenn man sich also hinstellen täte und der Linuxumgebung sowas wie

apt-get install tcsh; chsh -s tcsh

sagt, dann gibts beim nächsten ausführen von bash(.exe) nicht bash, sondern eben tcsh.
6. und letztens ist eben Punkt 4 die Hauptursache dafür, daß Linux-on-Windows nicht alles "kann". Irgendwas sagt mir, daß wenn man bash.exe im SYSTEM-Kontext ausführen würde, "mehr" möglich wäre.


Was offen bleibt, sind die Implikationen für die Sicherheit durch die Implementierung von Linux-APIs im Windowskernel. Ich würde mich zumindest nicht wundern, wenn das derzeit noch verhältnismäßig offen und ungeschützt wäre; Linux-on-Windows scheint derzeit eher noch proof-of-concept Status zu haben.

[IXS]

Zitat (RalphS: 24. April 2016 - 04:15)

6. und letztens ist eben Punkt 4 die Hauptursache dafür, daß Linux-on-Windows nicht alles "kann". Irgendwas sagt mir, daß wenn man bash.exe im SYSTEM-Kontext ausführen würde, "mehr" möglich wäre.

Wo widerspricht das meiner Aussage?
Wenn MS das Konzept weiter führt, werden irgendwann Linux Programme komplett unter Windows laufen. Aber eben nicht mit der veralteten Konzept, wie es immer noch unter Linux gehandhabt wird.

[DK2000]

Naja, das ist bei der Wortwahl alles etwas irritierend. Im Grunde genommen geht es hier nur um den 'Ubuntu user-mode' und hier dann auch nur die 'Ubuntu CLI', welcher ausgeführt wird. Ein Linux Kernel unter Windows wird es derzeit nicht geben und ist derzeit bei dem Konzept auch nicht geplant. Daher beschränkt sich die Kompatibilität nur auf Konsolenanwendungen ohne GUI (gut, eventuell Text Mode GUI). Von daher habe ich da selber so ein wenig Probleme, das Ganze Linux zu nennen. Das Ganze hat mehr was von Cygwin, nur dass man jetzt bei der Microsoft-Lösung die Linux CLI Anwendungen ohne Neucompilieren nativ ausführen kann, jedenfalls wenn sie von Canonical/Ubuntu kommen.

[RalphS]

Alles was keinen Zugriff auf die Hardware erfordert und was in einem "regulären" Benutzerkontext ausführbar ist, geht auch unter Linux-on-Windows. X bleibt außen vor. Curses & Co sind Terminalanwendungen, die sind (scheinbar) vollständig implementiert.

Ubuntu hat damit übrigens nichts zu tun, außer dem Namen und der Tatsache, daß Canonical mit MS zusammenarbeitet. Das ist aber pures Marketing; es gibt keine "ubuntu binaries" in dem Sinne, daß die sich von "red hat" oder suse" oder sonstwelcihen "Distributoren-Binaries" unterscheiden würden. Das sind alles LINUX-branded ELF binaries, die - wenn die richtige glibc da ist und die Suchpfade stimmen -- auch alle überall laufen (okay, Linux' Version der DLL Hell mal außen vor gelassen).

- Der Punkt ist der, wenn die Laufzeitumgebung zumindest binärkompatibel (=> ABI) ist, macht es dank MS' und Canonical's Anstrengungen keinen Unterschied mehr, ob man seine binaries auf einem Linuxsystem baut oder für ein Linuxsystem cross-kompiliert, oder unter Windows' LXSS nativ kompiliert; sämtliche solche binaries wären unter sämtlichen kompatiblen ABIs ausführbar. Sogar unter FreeBSD.

Aber unter Windows halt, derzeit, mit der Einschränkung, daß die benötigten Rechte dafür nicht da sind. Ein natives Linux würde "Permission Denied" liefern; da aber Windows das komplette Linuximage in einem Windows-Benutzerkontext ausführt, bekommt man unter anderem hintenrum einen (Linux-)Superuser, der aber nicht das darf, was man von ihm in einem Linux-Kontext erwarten würde.

Wie es jetzt praktisch weitergeht muß sich zeigen, aber ich halte es zumindest für "relativ problemlos" machbar (in einem technischen Kontext), die X ABI ins LXSS soweit zu integrieren, daß X-bezogene Aufrufe an den DWM weitergereicht werden.

Dieser Beitrag wurde von RalphS bearbeitet: 25. April 2016 - 00:59

[Stan]

echo 'nameserver 8.8.8.8' > /etc/resolv.conf

für apt-get etc, ping usw gehen noch nicht (https://github.com/M...indows/issues/5)

[IXS]

Zitat (DK2000: 24. April 2016 - 12:31)

Naja, das ist bei der Wortwahl alles etwas irritierend. Im Grunde genommen geht es hier nur um den 'Ubuntu user-mode' und hier dann auch nur die 'Ubuntu CLI', welcher ausgeführt wird. Ein Linux Kernel unter Windows wird es derzeit nicht geben und ist derzeit bei dem Konzept auch nicht geplant.

Schritt für Schritt, würde ich sagen. Es wäre schließlich sicherheitstechnisch katastrophal, wenn man unter Windows einen Linux Kern einbauen würde.
Es reicht doch vollständig aus, Programmbibliotheken zu erstellen. Sofern es sich um reine Linux und Android-Geschichten handelt, rennt ein Intel Prozessor den ARM Prozessoren locker davon, von daher könnte man sogar über Systeminterne Emulation nachdenken.
Microsoft MUSS etwas tun, weil eine gewisse Softwarebasis fehlt. Nicht nur wegen MS selber, sondern auch wegen Intel, die ihre Prozessoren nicht mehr verkauft bekommen und massenweise Leute entlassen. Die Prozessoren sind einfach insgesamt so flott geworden, dass 99% aller Belange mit billiger Hardware zu lösen geht. Die Wenigsten benötigen "Supercomputer" und 3D Berechnungen werden schließlich auch immer mehr über die GPUs bewältigt. Und, wer kennt das nicht: Man kauft ein Gerät, weil es dafür das gewünschte Programm gibt.

[Kirill]

Es gibt unter Windows keinen Linux-Kernel. Es gibt ein Linux-Userland, welches auf einem Linux-Emulator läuft. Aber keinen Linux-Kernel!

[RalphS]

Arme und andere Körperteile haben damit nix zu tun; das ist einfach x86_64-pc-linux-gnu, ganz normale AMD64-Architektur.

Emuliert wird auch nix. Funktionsaufrufe werden on-the-fly übersetzt, indem sie schlicht über Windows-APIs abgebildet werden. Also hat man so Funktionen wie

int gethostbyname(&host)
 {
return WIN32_gethostbyname(AF_INET4, &host)
 }

und nicht viel mehr (genannte Funktion fernab jeder Realität; nur als Beispiel).

Die (Linux)Kernel API implementieren ist andererseits aber ein bissel Pulverfaß. Zu viele Dinge sind unter Linux als 3rd-party-Kernelmodul implementiert oder von einem abhängig und API ist alles andere stabil; Microsoft müßte, um da mitzuhalten, jeden Monat ein Update für LXSS ausliefern - insbesondere, jedesmal wenn Canonical am Kernel was schraubt, muß Microsoft bei sich auch schrauben, damit Kompatibilität gewahrt bleibt.

Ist jetzt natürlich die Frage, wie realistisch eine Umgebung wäre, die unter Windows auch den Linux-Kern dynamisch laden würde. So oder so würde das dann tatsächlich in Paravirtualisierung enden und Linux den Peter zuschieben, was die "erfolgreiche" Funktion unter Windows angeht. Das wäre dann nämlich Sache der Kernelentwickler.

[achilleus]

Zitat (Sturmovik: 23. April 2016 - 18:57)

Und daher rührt auch das Problem, dass die im Linux-Subsystem laufenden Programme nicht an die Hardware rankommen => kein Xserver (gut, brauch man eher weniger), keine Netzwerksockets und weitere Einschränkungen.

https://www.reddit.c...apps_from_bash/

wegen kernel:
eingesehen, hatte das falsch aufgeschnappt.