Windows 10 Insider Preview Build 14316 - bash a Windowsban

 ( trey | 2016. április 6., szerda - 20:17 )

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:

Idézet:
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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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

Legalabb nem "kotelezo" telepiteni... :)

Kíváncsi leszek, hogy mikor lesz az Ubuntu-ban

"apt-get install windows10"

:D

--
trey @ gépház

azaz :D

Vagy legalabb "apt-get install powershell" =)

Nem kell, automatikusan jön majd a popup :)

Eljön majd az idő, amikor windows forkokkal lesz tele az internet :D
-------------------------------------------------------------------------
Nem, de lehetne.

Hello World!

Udv,
Marci

Gipszben van a gyökér.

:)

Milyen X-szel használod? Mennyire használható az X?

Mingw. Nincs még sok tapasztalatom, de a Firefox gyakorlatilag nem működik, folyton (pár másodpercenként...) összeomlik. A gimp ment gond nélkül, addig a kis ideig. xterm nem indult el.

Üdv,
Marci

de a Firefox gyakorlatilag nem működik, folyton (pár másodpercenként...) összeomlik.

Ezt natívan is tudja :D
Pl. az arm64-es buildje teljesen használhatatlan.

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

Ugyanez nálam is, felment a frissítés, developer módban volt eleve, a feature viszont nem volt meg :(
Azóta az iso sincs amivel próbáltam. Valami spéci beállítás nem kell neki? Pro vagy Home verzió?

Nálam Pro, spéci dolgot nem tudok.

Üdv,
Marci

nálam is pro 14295 és nem dobja fel a frissítést, nincs beaktiválva, de ennek nem kéne problémát okozzon.
--------------------
http://grant-it.com/

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/windowsinsiderpreviewadvanced
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 :)

Azóta minden nap bekapcsoltam és rányomtam a frissítésre, ma el is indult a 14316 letöltése. Mielőtt még bárki meggyanúsítana, első nap beállítottam, azóta a konfigon nem módosítottam csak próbálkoztam :)

--------------------
http://grant-it.com/

Ugyanez volt nekem is. Telepítés, rögtön a megfelelő beállítások elvégzése, és az update 2-3 nap után érkezett csak. Fene se érti miért jó ez nekik.

Szerintem csak annyi frissitest engednek ra a szervereikre amennyit elbirnak. Ebben az esetben elofordulhat hogy a sor vegen allok csak napok mulva kapja meg.

Egy MS szintű cégnél ez ilyen komoly probléma volna? Engem nem érdekel ha limitált sebességgel jön az update, de akkor ne azt írja hogy az ön rendszere naprakész, hanem azt, hogy a frissítés várólistás vagy valami.

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, hogy limitálják a hiba kiterjedtségét, ha valami komoly hiba van az aktuális változattal. Néhány ezres környezetben is így csináltunk tucatnyi éve.

Üdv,
Marci

En sem. Ha jol emlekszem mobile-os insider buildnel talan volt is ra pelda.

"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.

-

Amúgy, nem Photoshop! :D

Üdv,
Marci

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.

Ez egy elég alaposan felépített áprilisi tréfa. ;)

kellett már az ssh-t támogató git a visual studioba biztos...

Nemsokara linuxra is Visual Studioval fog fejleszteni mindenki. :)

Ha rendesen fut wine-al meg windows sem kell hozza.

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

Akkor csak nem sikerült megérteni, hogy miről is szól ez az egész...

azért az unibin != uniplatform azért ne keverjétek össze

Ú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-and-unix-support-in-windows.aspx

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."

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.

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

Hát a *nix rendszereken eddig se a bash volt az alap :-P - amire gondolhatsz, az a *nux.

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

Idézet:
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

A legutolsó bekezdésben van a lényeg. Enélkül ez nem sokkal több, mint egy ultralight VM.

Pontosan.

--
trey @ gépház

Bizonyítja az az utolsó bekezdés, hogy VM? Kíváncsi vagyok mi lehet a mögötte rejlő technika, de számomra nem jelenti azt, hogy ettől VM lenne. A wine pl nem vm (tévedek?) és a wine-re is igazak a fentiek.

Senki nem mondja, hogy ez egy VM, hanem hogy a fentiek alapján funkcionálisan nem sokkal ad többet.

Ez egy Lime (Linux In Microsoft Enterprise) :) (szerintem Linux API-k mögé tolt Win API wrapper.)

Szerintem simán a régi coLinuxot élesztették újra a Canonicalnál, szóval ez egy UserModeLinux, frissített összetevőkkel.

azt irtak valahol, hogy syscall translation

--
NetBSD - Simplicity is prerequisite for reliability

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 Project Astoria mégsem a temetőben végezte :P

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_Informatikai_Kar

Azóta kijött több info is és úgy tűnik tényleg syscall translation történik, csak félrevezető uname kimenetet hazudnak a userlandnek...

https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-overview/

Annyira komolyan veszi a Microsoft a Linuxot, hogy a hír mellé még a magyar nyelvű hup-on is aktiválta az összes fizetett trollját. :D


Normális HUP-ot használok!

Huu...te aztan az informatika utoeren tartod am az ujjad :D

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.

*GNU\Windows

nyilvan azert, amiert egy valamire valo bongesz ilyen useragentet hasznal: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.110 Safari/537.36 Vivaldi/1.0.435.38

--
NetBSD - Simplicity is prerequisite for reliability

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.

Hát úgy néz ki ezzel engem már meg tudott venni a M$ :(

---------------------------------------
Devmeme - fejlesztői pillanatok

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).

Lehet hogy a wine mar egy lepessel tovabb is tart ott amit valojaban akkarsz.
A tobbi inkabb csak license kerdes.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

UML roviden:
http://www.cse.psu.edu/~buu1/teaching/spring06/slides/uml.ppt

Megy mar az OpenArena ?


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

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.)

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 :)

"jobban teljesít, mint a Linux"

Kizart dolog!

Ezt majd a tesztek megmondják.

1. Egy plusz reteg van benne, szerintem nevezhetjuk emulacionak.
2. Vinfo$ fut alatta. Ez mar onmagaert beszel. Tudod: kek halal, virusirtok, stb.

Ja, hogy te elborult Winhater vagy, ahelyett, hogy mérnök lennél. Akkor felesleges vitatkozunk, köszi.

Elvegre is Unix-Linux portalon vagyunk.
A Vinfo$ pedig koztudottan tul van bloatelve (bonyolitva).

De ettől még nem lesz a Linux ab ovo jobb teljesítményű, hogy azt hiszed róla. Majd a tesztek megmondják. De mivel fanboy vagy, nem lehet veled úgy beszélni, mint szakember a szakemberrel. Sajnálom :(

Teszteltem en pl pgsql-t.
20%-kal gyengebb volt a vinfo$.
Tuningoltuk, ugy is 8%-kal gyengebb volt.
De majd jol "grep -nir shit"-eljuk a Linux forrasat es kiderul itt is az IGAZSAG!

Még mindig nem érted: te a Windowsos implementációt tesztelted, nem a kernelét.

Most majd ugyanaz a bináris fog futni Linux és Windows alatt, így a kernel teljesítményét méred majd meg.

Van ra egymillio forintom, hogy alul fog maradni a vinfo$.

köz-tu-dot-tan

ja, úgy mindjárt más :)

Jogos, elirtam. Koztudodtan.

LOOOOOOOOOOOOOL :D

abaLOL :-)

+1

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.

+1

> 2. Vinfo$ fut alatta. Ez mar onmagaert beszel. Tudod: kek halal, virusirtok, stb.

Ez a komment is önmagáért beszél. :)

Örülnék ha jobb lenne. Egésséges versenyhelyzet jót tehet a linugz kernelfejlődésnek + a sok linuxon-egyszerű-winen-szívás projekt is lelkesebbé válhat. :)

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.

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..)

Mert tudsz mellette natívan futtatni Office-t, Exchange-t, meg sok MS-only szoftvert Wine nélkül.
Majd kiderül, hogy a Linux natív + Wine a jobb megoldás, vagy a Windows natív + Linux emuláció.

Ez nyilvan azon mulik, mi a fokusz: excel tablazatot szerkesztesz fomusoridoben vagy programozol. Vagy olyan ceges kornyezetbe kerulsz, ahol nincs valasztasi lehetoseged :)

Nálam eddig is windows native + linux virtualbox volt, most maximum a virtualbox helyett ez lesz.

En lusta vagyok felrakni, de twitteren lehet talalni egy-egy erdekesebb kepet.

Van valaki aki kiprobalta mar?

Egy Hello World-nel komolyabbra gondoltam, de mostmar legalabb leesett hogy mi az erdekes a masodik kepen. :)

És az elsőn leesett, hogy egy Windows 10-beli Ubuntun fut egy linuxos Firefox, aminek a Windowsos Xming az X Servere és arról HUPozok? :D
(nincs Firefox a tálcán van viszont X Server)

Üdv,
Marci

Nem. Azt hittem az csak amolyan mai-ujsag-a-túsz-kezében bizonyíték hogy tenyleg te csinaltad a kepet es nem csak netrol szedted. :)

Én próbálnám de csak nem megy fel :(

Persze. Tegnap feltettem simán, ahogy azt Marci is leírta feljebb (win update, Programs).
Hálózat nem megy alatta valamilyen oknál fogva így apt-get update-et sem sikerült kicsikarni belőle. De megoldják ezt mire jön a push a production-be.

Jah, resolv.conf üres volt valamiért
Gondolom mivel ubuntunál a resolv.conf-ot valami szolgáltatás töltené fel tartalommal, az meg nem indult el init scriptek híján...

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