Windows 10 Insider Preview Build 14316 - bash a Windowsban

Microsoft, Windows

Bash a Windows 10 Insider Preview Build 14316-ben

Gabe Aul ma bejelentette, hogy a "Fast ring"-et követő Windows Insider-ek számára elérhető az Insider Preview Build 14316. Érdekessége egyebek mellett, hogy megjelent benne a korábban már beharangozott bash szolgáltatás:

Run native Bash on Ubuntu on Windows: In this build, you can natively run Bash in Windows as announced last week at Build 2016. To do this, you first need to turn on Developer Mode via Settings > Update & security > For developers. Then search for “Windows Features” and choose “Turn Windows features on or off” and enable Windows Subsystem for Linux (Beta). To get Bash installed, open Command Prompt and type “bash”. For more details, see this blog post.

Részletek a bejelentésben.

( trey | 2016. 04. 06., sze – 21:19 )

Na erre kíváncsi vagyok. Nyár óta először indítottam el a W10 virtuális gépem. 7%-nál áll a frissítés.

--
trey @ gépház

( AlexC | 2016. 04. 06., sze – 21:22 )

Legalabb nem "kotelezo" telepiteni... :)

Hogy sikerült telepíteni?
Bent vagyok az insider programban, letöltöm az insider oldalról a win10 iso-t, de a stabil build települ.
Pár napja sikerült letöltenem egy tényleg insider buildet, az eggyel korábbit, az települ is rendesen, frissül is az 14316-ra, de nincs ott a linux subsystem a windows features alatt, ahonnan elvileg fel kéne rakni (developer mód bekapcsolva)

14295-ön volt az Insider-es gépem, onnan ment fel 14316-ra. Developer módban volt eleve, simán bekapcsolható volt a feature (Windows Subsystem for Linux (beta) néven keresd), bekapcsoltam, újraindítást kért, utána parancssorból >bash, Y, profit!

Üdv,
Marci

Sajnos nem segít.
Először is azt írja, hogy "Windows 10 Anniversary Edition - Build 14316 Available as of 4/6/2016 through the Insider Fast Ring"

Rákattintottam a linkre, bejelentkeztem, "Welcome back, Insider" alatt közvetlenül ott a letöltés opció, de ez a stabil kiadást tölti le, nem az insidert.

Szerencsére tudom, hogy az insider iso innen letölthető: https://www.microsoft.com/en-us/software-download/windowsinsiderpreview…
Csakhogy amit innen tudok letölteni, az az 14295-ös build.

Ez fel is van telepítve tegnap óta, és be van állítva minden, ami ahhoz kell, hogy frissüljön az 14316-os verzióra, de nem teszi. Eddig csak pár Windows Defender frissítés érkezett. Olvastam valahol, hogy egy friss telepítés után akár 24 óra is kell hogy megjelenjenek a frissítések. Milyen nevetséges ez?

A vicces, hogy két (három?) nappal korábban ugyanezt eljátszottam. Felment az 14295, nem volt elérhető frissítés, rá másnapra már volt, fel is ment, de nem volt benne a linux compatiblity layer. Most már látom, hogy valószínűleg amiatt, mert 32 bites változatot telepítettem, itt pedig írják, hogy 64 bit kell neki. Úgyhogy a jelenlegi telepítésemet is buktam. Úgyhogy töltök le mégegy iso-t :)

Teszt buildek teritesere gondolom nem aldoznak annyit mint amennyit megtehetnenek.
Egyebkent tud p2p is updatelni a Win10, de nekem alapertelmezetten kikapcsolva volt*, plusz PCs on my local network volt kivalasztva.

*Legalabbis nem emlekszem hogy piszkaltam volna ezt a beallitast.

"Nem lennék meglepve, ha több fázisú lenne a buildek térítése"

Én igen, megmondom miért. Egyrészt kipipáltam hogy kérem az insider preview-t, ott már egyszer elfogadtam hogy instabil változatot kapok. Másodszor annak a beállításaiban kiválasztottam azt az opciót, miszerint a lehető leggyorsabban és a legújabb buildekhez szeretnék jutni. Ott is elolvashattam, leokézhattam (?) hogy ez egy instabil valami lesz.

Kifejezetten egy tesztelésre szánt verzióról van szó, aminek pont az volna a lényege, hogy hibákkal együtt érkezzen, hogy aztán azt majd az user visszajelezze. Ne akarjanak már megvédeni a hibáktól... Amiről te beszélsz az oké a stabil verziónál, de ne egy még bétának se nevezhető valaminél.

( horvatha | 2016. 04. 07., cs – 07:04 )

Akkor ez most tényleg nem április 1-i tréfa.... Azért még néha elő kell vennem a logikámat, ami meggyőz, hogy ez valóságos, mert a szubjektív érzetem azt súgja, hogy valami tévedés van: hiba a mátrixban vagy 3. szintű álomban vagyok és most akarják elültetni belém egy ötlet eredetét... :-)

Marhára kíváncsi vagyok, mi lesz ebből.

( dark100 | 2016. 04. 07., cs – 07:10 )

Eltartott egy darabig mire rajottek, hogy a universal app az elf binaris. De legalabb soha tobbe nem kell senkinek windowsra fejlesztenie / portolnia semmit.

( mrev | 2016. 04. 07., cs – 09:28 )

Úgy emlékeztem, hogy a Windows NT vonal eleve tartalmazott egy posix kompatibilis alrendszert. Most megnéztem (https://hu.wikipedia.org/wiki/POSIX) és tessék, a Windows ott van a felsorolásban. Ha ez komolyan vehető, akkor most "csak" annyi történik, hogy kiegészítik a posix funkcionalitást a Linux bővítményeivel.

Más kérdés, hogy 30 évvel ezelőtt a posixot nem nagyon tolták előtérbe. Azt mondták, van ugyan valami posix furcsaság, de az "igazi" fejlesztők natív Windows API-t használnak. Úgy dereng, hogy állalmi tenderkiírásoknak való megfelelőség kedvéért vették be a posixot.

--
ulysses.co.hu

Ez egy egesz jo hivatalos osszefoglalo:
http://social.technet.microsoft.com/wiki/contents/articles/10224.posix-…

Ebbol kiderul, hogy jol emlekeztel:
"The subsystem was included because of 1980s US federal government's requirements listed in Federal Information Processing Standard (FIPS) 151-2. Versions Windows NT 3.5, Windows NT 3.51 and Windows NT 4 were certified as compliant with the FIPS 151-2."

( Dacr (nem ellenőrzött) | 2016. 04. 07., cs – 09:54 )

Tipp: 5 éven belül az újságok újabb nagy startup üzleti exitről fognak cikkezni, miszerint a Microsoft felvásárolja a Canonicalt, Mark pedig újabb turistautat tervez az űrbe.

( j | 2016. 04. 07., cs – 10:10 )

ezzel aztán tényleg kihúzták a *nix rendszerek méregfogát. nem adok egy évet, és végleg elsorvadnak.

Azért még mielőtt magunk alá pisálunk a gyönyörtől, néhány dolog:

First, this is the first time we’re releasing this technology – it’s marked as beta for a reason: We know that there are some rough edges and that some things will break! Do not expect every Bash script and tool that you run will work perfectly – there will be gaps. But by trying out this feature, you’ll help us figure out what we need to work on in order to greatly improve our reliability, coverage, and reach.

Second, while you’ll be able to run native Bash and many Linux command-line tools on Windows, it’s important to note that this is a developer toolset to help you write and build all your code for all your scenarios and platforms. This is not a server platform upon which you will host websites, run server infrastructure, etc. For running production workloads on Ubuntu, we have some great solutions using Azure, Hyper-V, and Docker, and we have great tooling for developing containerized apps within Windows using Docker Tools for Visual Studio, Visual Studio Code and yo docker.

Third, note that Bash and Linux tools cannot interact with Windows applications and tools, and vice-versa. So you won’t be able to run Notepad from Bash, or run Ruby in Bash from PowerShell.

--
trey @ gépház

Olvastam, csak nem hiszem el (különben az uname miért Linux 3.4.0+-t ad vissza pontosan ugyanolyan 2013-as build dátummal, amely megegyezik a Google android-build@intel-otc emulatorban elérhető kernellel? ;).

Vagy hát syscall translation ez is, hogy a Linux kernel usermodeban fut és az alatt a Linux programok, csak definíció kérdése... :)

A HWSW Free! -n azt mondta a Microsoft-os előadó, hogy régen a Microsoft megpróbálta belerakni a Linux alapjait a Windows-ba, és ezt most újra elővették.

--------------------------------------------------------------------
http://www.kmooc.uni-obuda.hu/
http://www.memooc.hu/
http://www.hbone.hu/hu/hirek/hbone_workshop
http://videotorium.hu/hu/channels/details/814,BME_Villamosmernoki_es_In…

( kpocza | 2016. 04. 07., cs – 21:46 )

Ellenben (ahogy az ebbe a topicba belinkelt képeken is látszik) azt írja ki az uname, hogy GNU/Linux.
Miért nem GNU/Windows?
Hiszen itt mások mellett a GNU programok Linux kernel helyett Windows kernelen futnak. Persze a GNU/Linux kifejezést lehet másképp is értelmezni, de Ubuntu esetében nekem nem ez az értelmezés tűnik természetesnek.

Ha mondjuk egy olyan magyarázatot adtál volna, hogy azok a shellscriptek, amelyek az uname kimenete alapján hoznak platformspecifikus döntéseket és az ezekkel való kompatibilitás megőrzése a cél, akkor azt mondom, hogy elfogadom.

A böngészős indoklás sántít, mégpedig:

Az én valamire való böngészőm (MS Edge 13) a következő UA stringet adja:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2486.0 Safari/537.36 Edge/13.10586

Egy másik valamire való böngésző Windows 8.1-en futtatva pedig a következőt:
Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.110 Safari/537.36

Ja, hogy Windows NT 6.3-t ír? Az gyakorlatilag a Windows kernel veziószáma. Csak a 10-esnél hozták szintronba.

A böngészős indoklás nem sántít, mert ugyanarról szól: azért "karácsonyfa" a böngészőverzió string már szinte mindenkinél (és senkit nem az érdekel, hogy Windows NT mennyit mond), mert a browserfüggő kódok ezekre próbálnak matchelni, és ebből próbálnak túlokos következtetéseket levonni - nos, az uname kimenetét pont ugyanígy próbálják különféle scriptek "feldolgozni", és az alapján túlokos következtetéseket levonni.

( csabka v | 2016. 04. 08., p – 10:53 )

Az lenne a fair, ha lenne UsermodWindows is, így lehetőség lenne ezt fordítva is megcsinálni, hogy egy szabványos interfészen keresztül a Windows-os kernelhívásokkal windows-os programok futtatását lehetővé tenni natívan, így nem kellene wine vagy VM

Nyilván, mivel a Linux nyílt forráskódú és van Usermodlinux, így az MS ezt meg tudta tenni (szép munka amúgy részükről bár egy ps auxf parancs kimenetét megnézném).

( abalole | 2016. 04. 08., p – 11:41 )

Itt megprobaljak elmagyarazni, hogy mukodik:

that means apt, ssh, rsync, find, grep, awk, sed, sort, xargs, md5sum, gpg, curl, wget, apache, mysql, python, perl, ruby, php, gcc, tar, vim, emacs, diff, patch...

"Right, so just Ubuntu running in a virtual machine?" Nope! This isn't a virtual machine at all. There's no Linux kernel booting in a VM under a hypervisor. It's just the Ubuntu user space.

"Ah, okay, so this is Ubuntu in a container then?" Nope! This isn't a container either. It's native Ubuntu binaries running directly in Windows.

"Hum, well it's like cygwin perhaps?" Nope! Cygwin includes open source utilities are recompiled from source to run natively in Windows. Here, we're talking about bit-for-bit, checksum-for-checksum Ubuntu ELF binaries running directly in Windows.

"So maybe something like a Linux emulator?" Now you're getting warmer! A team of sharp developers at Microsoft has been hard at work adapting some Microsoft research technology to basically perform real time translation of Linux syscalls into Windows OS syscalls. Linux geeks can think of it sort of the inverse of "wine" -- Ubuntu binaries running natively in Windows. Microsoft calls it their "Windows Subsystem for Linux". (No, it's not open source at this time.)

( persicsb | 2016. 04. 08., p – 13:08 )

Kíváncsi lennék, hogy az egyes toolok teljesítménye milyen lesz Windows kernel alatt. Ha az jön ki, hogy jobban teljesít, mint a Linux, az nagy szívás a Windows haterekre nézve :)

Elvégre felnőtt (?) értelmes emberek vagyunk, és képesek vagyunk anélkül beszélni olyan dolgokról is, amiket esetleg kevésbé kedvelünk, hogy a fos ömlene a szánkból :) Az összes ilyen megnevezés, mint a Vinfo$, microfos, binux, bubuntu, fosx, stb szánalmas, gyerekes, éretlen hozzáállásra vall, és nem szabadna hogy helye legyen akármilyen fórumon függetlenül attól, hogy melyik oprendszert favorizáljuk és melyiket nem.

Ez egy érdekes kérdés, sztem lassabb lesz a Windows kernelen.

Azt tudjuk, hogy a Windows kernel felett az NT alkalmazásokat egy un. Windows NT subsystem (alrendszer) futtatja. Van és volt POSIX alrendszer is, gondolom ezt tuningolták, adaptálták Linux kernel interfész kompatibilis subsystemmé (LXss).

A Windows kernel minden egyes objektumhoz, ami lehet egy fájl, könyvtár, szinkronizációs/IPC entitás (semaphore, mutex, shared memory, event, stb.), process, thread, stb. egy ACL-t rendel. Az ACL-ben, hozzáférés leírók vannak felsorolva, amelyek az objektum típusától függő műveletekre, felhasználó és csoport szintű engedélyeket, tiltásokat specifikál. Ez nagyon sok felhasználóra és csoportra megteheti. Az objektumokhoz való hozzáféréskor a security manager (kernel komponens) le kell, hogy ellenőrizze a jogosultságokat. Ez nagyságrendekkel komplexszebb dolog, mint a Linux alapértelmezetten egyszerű jogosultságkezelése esetében. A Windows processek ettől függetlenül is sokkal heavyweight-ebb objektumok a Linuxos megfelelőiknél, a szálak már viszonylag elég lightweight-ek.

Ha én terveztem volna a LXss-t, akkor simán ezek fölé a komplex entitások fölé pakoltam volna egy adapter réteket, amely Linux kernel interface kompatibilitást ad. Leginkább azért tettem volna így, hogy megtartsam a későbbi lehetőségét annak, hogy a Windows és Linux processek IPC-n kommunikálhassanak egymással.

Persze a fenti csak szimpla okoskodás, le kell mérni különböző valós workload-okon. De ettől függetlenül én semmiképp sem számítok nagyságrendi eltérésre, max pár 10%-ra, az meg kit érdekel.
Egyrészt a performancia nem számít számottevően itt, ugyanis ez a dolog fejlesztőknek készül első körben és nem szerverekre. Ha a jövőben támogatott lesz a szerver oldali használata is az LXss-nek, akkor ott nem a teljesítmény számít, hanem a skálázhatóság. A skálázhatóság pedig nem egy instance-on értelmezett, hanem több instance-on és az alkalmazáson/annak fejlesztőjén áll vagy bukik.

( uid_19334 | 2016. 04. 08., p – 17:23 )

Hm. Egye-fene, kiváltom a zingyenes win10 licencet, talán lesz ebből még valami.

(Bár még mindig nem tudom miért jobb úgy ubuntut futtatni hogy a ms elküldözgeti magának amit csinálok, mint ha mondjuk ubuntut futtatnék natívan..)

( Hijaszu | 2016. 04. 09., szo – 05:51 )

Na ez se lesz ezek szerint natívabb mint a cygwin :D