A nap képe: Bash coming to Windows

Bash coming to Windows

Részletek a Canonical alkalmazásában álló Dustin Kirkland blogbejegyzésében.

Hozzászólások

Meghülyült a világ.
A Windows Linux akar lenni, a Linux meg Windows akar lenni.

--
robyboy

"Linux is a cancer that attaches itself in an intellectual property sense to everything it touches"

Na de mi lesz a powershellel akkor? :D

Meglehetősen nagy lépés ez! Alig várom, hogy kipróbálhassam. Ez egy új korszak kezdete

De mi lesz igy azokkal, akiknel az eletuk resze utalni Microsoftot (vagy a Windowst)?

Esetleg Oracle?

Idén korán jönnek az ápr. 1-i hírek :)

A poszt címe egy kicsit félrevezető, vagy talán trey valamiért nem akarta a velős igazásgot leírni. Ő tudja miért, de fel sincs taggelve a hír Ubuntu-ra.

Na, szóval, annak aki nem rágja át magát Kirk blogposztján és nem siklik át a szee ezen a Bash comint to Windows részleten annak a hír nem ez.

A hír az, hogy egy teljes értékű 14.04 (amit majd 16.04-re fognak nyáron firssíteni) Ubuntu server kiadás user space-e lesz elérhető.

Nem egyszerűen Bash, hanem komplett és natív ELF binárisokat fog futtatni ez a shell. Plusz még python, perl, awk, sőt gcc meg lényegében bármilyen szerver eszközt lehet majd használni és apt-get segítségével akár telepíteni is.

Két dolog nem lesz bennne... Linux kernel és init rendszer.

Szerintem így már ütősebben hangzik a hír. Mondjuk nyilván ez nem a megrögzütt Unix és Linux felhasználóknak szól ez a történet, hanem azoknak a rendszergazdáknak és adatbányászoknak akiknek esetenként vindózt kell használni. Én két évig fejlesztettem vindóz alatt és egyszerűen agybajt kaptam, hogy a jól megszokott parancssori rutin dolgaimat nem tudtam használni. A Cygwinnel és powershellel meg mindig is az volt a baj, hogy "ami csak olyant mint ... az nem az" mert ez az.

Jó, de ez mire lesz jó? Egy random nagy halmaza a Linuxos dolgoknak nem fog működni (vagy csak a Linux-birodalmon belüli dolgokat fogják látni a Linuxos cuccok).
A Cygwin egyik alapvető problémája pl. a Windows-os path eltérő konvenciója, ezt itt sem tudják megoldani, logikusan, hiszen sem a Windows alatt nem lehet névkonvenciót/szemantikát cserélni, sem a Linuxban. Így viszont az orbitális szopás kategóriája a két "világ" közötti átjárás - na akkor meg mennyivel jobb ez, mint egy VM?

Tehát pl. a ps parancs mutatja a Windowsos programokat, lehet nekik SIGSTOP-ot meg SIGCONT-ot küldeni. A top mutatja a Windowsos programok CPU használatát (is), az fdisk-kel tudom partícionálni a gép diszkjeit (ehhez "természetesen" VT100-kompatibilis terminált emulál neki a Command Prompt), a gpm megkapja a terminál fölött kolbászoló egér eseményeit, és lehet pl. mc-ben az egérrel matatni, az lsusb mutatja az USB device-okat, a libusb-t használó programok direktben el tudják érni az USB device-okat, a dd if=/dev/zero of=/dev/sda5 üresre gyalulja az első logikai partíciót az első diszken, stb.
Mondjuk izgalmas kérdés, hogy a mount parancs mit és hogyan csinál... :D

Itt van egy video ahol kiveseznek nehany kerdest. Kb. a 10. percnel van szo a top-rol/htop-rol.
Nem vagyok benne teljesen biztos, de nekem ugy tunik mintha eloszor a top-ot mondana hogy nem mukodik, de aztan kijavitja hogy az htop az ami nem, de kesobb megoljak hogy az is menjen. Hogy mit fog mutatni azt nem tudom.
Kb. ket heten belul lesz kiprobalhato -beta- verzio, jelenleg a developereket segito parancsori eszkozokre fokuszalnak es nem a guis dolgokra(mc, htop) mivel sok olyan terulet van linux oldalrol amit nem tudnak egybol biztositani.

En kb eddig neztem, ha valaki meg talal benne erdekeset irja le es javitsatok ki ha valamit rosszul irtam.

> Azmiazhogy server kiadas?

Az, hogy nem desktop. Az Ubuntu kétzféle imidzset kínál a felhasználóknak. Az egyik a desktop felhasználóknak, ebben van X meg window manager és egy raklap GUI-s alkalmazás. A másik a server kiadás ami jellemzően szereverekre készült.

http://releases.ubuntu.com/14.04.4/

A repository persze mindkettő mögött ugyanaz. Vagyis a rendszergazda bármikor tud desktopot serverkét használni és viszont.

> Konkretan az X mukodni fog vagy nem?

Sajnos, egyelőre nem.

>> Azmiazhogy server kiadas?
> Az, hogy nem desktop.

Kosz, marha sokat segitettel:D

> Az Ubuntu kétzféle imidzset kínál a felhasználóknak

Akkor azzal pontos vagyok, hogy azok fognak mukodni, amik megtalalhatok a server image-en ES nincs fuggoseguk kivulrol?

>> Konkretan az X mukodni fog vagy nem?
> Sajnos, egyelőre nem.

Kesobb?

> Kosz, marha sokat segitettel:D

Há fújd fel :) ha egyszert két imidzs van... a server és a desktop akkor a server az amelyik nem a desktop :)

> ES nincs fuggoseguk kivulrol?

Mit értesz kívül alatt?

Nincs kernel és nincsen init rendszer. Minden más van. Amihez kernel kell vagy init rendszer azok nem fognak működni. Minden más viszont igen.

> Kesobb?

A rossebb se tudja :) Ami tudható az az, hogy Vulkan/EGL/GL alkalmazások futtatásának elvi akadálya nincsen, vagyis egy XMir akár futhat is és abban pedig mennek a legacy X appok és az Ubuntu touch appok is.

Szóval ha direktbe X nem is lesz, azért valami lesz.

Én személy szerint oda lennék meg vissza, ha lenne bármilyen megoldás arra, hogy Ubuntus Qt/QML alkalmazásokat akár egy XMir session-ban futtatni lehetne. Ugyanis az Ubuntu SDK-t amin én is dolgozom csont nélkül tudom már most is portolni Windowsra. Magát az IDE-t egy mozdulat áttolni, az Ubuntu UI Toolkitet vagyis a UI widgeteket is le tudom fordítani Windows-ra (meg OSX-re is) Eleve törekedtem ilyen portolható SDK-t csinálni. Viszont a build és a runtime cuccok azok nem voltak portolhatóak. Ennek a most bejelentett cuccnak a segítségével egy LXD containeren viszont a komplett Ubuntu phone API-t tudom portolni és ha az XMir session járható út, akkor konkértan egy az egyben ki tudok adni egy komplett Ubuntu SDK-t Windows-on. Ez pedig elképesztően nagy lehetőségek előtt nyitna kaput.

Az utolsó bekezdésre: ez tényleg elég menően hangzik, köszönöm! A portolásnál általában én is a build toolokkal szoktam szívni. Elsőre a "minek" volt erre az egészre a kérdésem, de most azért már látok lehetőségeket a dologban. Kíváncsi leszek, mi lesz belőle.

Bár egyik kolléga szokta mondogatni: a Linux legyen Linux (no wine), a Windows meg Windows (no cygwin & tsa) :-).

Nincs kernel és nincsen init rendszer. Minden más van. Amihez kernel kell vagy init rendszer azok nem fognak működni. Minden más viszont igen.

Bocs, de ez sületlenség. Mindenhez kell kernel, mert a user-space magában semmit nem tud csinálni, az egész külvilágot a kernelen keresztül "látja" csak. Tehát a kérdés az, hogy mivel a Linuxos kernelt nem rakták be egy az egyben, na akkor mely funkcionalitását emulálják, és melyiket nem. Nyilván ebből adódik, hogy melyik programot lehet használni, és melyiket nem.

Igen, ha alapvetően a céges infrastruktura windows alapú, és már van windows a fejlesztői gépeken, viszont linuxra is kell fejleszteni,
akkor jó eséllyel nem kell azzal szórakozni, hogy virtuális gépet telepítsek, és abba pakoljam fel, ami kell, hanem ezt így kb. megkapom.

Nekem vannak ezzel a koncepcióval fenntartásaim: erre ez nem feltétlenül lesz jó (igazából marad az eredeti kérdésem: na mire is jó ez?), mert ha Linuxra kell fejleszteni, akkor abban a környezetben kell fejleszteni, amiben futnia kell neki, erre igazából a VM az egyetlen értelmes megoldás.
Ahogy a Linuxos gcc is tud cross-compile-olni PE binárist, mégsem teszi ezt az ember, mert normálisan tesztelni nem lehet (hiába fut pl. wine alatt, ha nem egyezik a környezet 100%-ban, akkor nem lesz releváns a végső futási környezetre vonatkozóan a tesztelés - én meg attól minden fejlesztőt eltiltanék, hogy saját kis alternatív valóságában fejlesztgessen, hogy utána a projekt végén bukkanjanak ki a szögecskét a zsákból).

"na mire is jó ez?"

Nezd meg szerintem a fentebb mar linkelt videot. A command-line dev tool-ok futtathatosaga a kimondott cel.

Szerintem a rovidtavu celjuk ezzel nem az, hogy a hardcore linux usereket atcsabitsak windowsra, hanem az, hogy ne kezdjenek fejlesztoket vesziteni csak azert, mert linuxon jobb CL eszkozok vannak. Masreszt: ne ismetlodhessenek meg (vagy legalabbis nehezebben), hogy uj technologiak nem erhetoek el windowson a fejlesztoknek amiatt, mert azok linuxra keszulnek el elsosorban. Kb. ilyenek voltak amire emlekszem a node.js es a redis. Mindketto az MS aktiv kozremukodesevel portolodott vegul windowsra. Egy jobb megoldas, ha az egesznek az elejebe mennek, es megoldjak hogy ezek es a kesobbi hasonlo eszkozok egybol mukodjenek windowson portolas, idoveszteseg nelkul.
Igy ha egy windows-os dev a jovoben meglatja hogy van egy uj NextBigThing, de ahhoz linuxot kellene telepitenie, akkor nem kell felraknia linuxot. Igy vegso soron kisebb az eselye hogy linux felhasznalo lesz belole.

A lenyeg, hogy a fejlesztoket megtartsak a sajat okoszisztemajukon belul, es ha lehet visszacsabitsanak annyit amennyit csak tudnak.
Mint megtanultak a Windows Phone "sikerebol", nem a platform josaga donti el egy platform sikeret, hanem a ra keszult appok. A windows-on maradt fejlesztok nagyobb esellyel fognak windows-os appokat fejleszteni mint linuxost, es jo esetben nagyobb esellyel fognak Microsoft-os eszkozoket(visual studio) -mostmar akar linux-os debuggolasra is - es Microsoft-os szolgaltatasokat hasznalni (Azure).
A Xamarin-t is azert vettek meg es tettek ingyenesse btw, hogy kevesbe tavolodjon a ket .net implementacio, es a leheto legkevesebb raforditassal lehessen iOS es Android mellett Win10/Win10 mobile verziokkal kijonni igy csokkentve az "app gap"-et. Ezert penzelik/penzeltek a Unity3D-t is hogy ingyenesen tudjanak a U3D hasznalok buildelni WP8-ra(8.1-re, 10-re, stb). Megvettek a Visual Studio Tools for Unity-t es ingyenesse tettek.
Ami pedig nem .NET-et hasznal, arra pedig megprobalnak mas megoldast talalni (bridge-ek az elozo buildrol).

Es ez az uj szemleletvaltas: nem erovel probalnak a platformnal tartani mint eddig, hanem -mint ahogy a google elkezdte,- annyi josagot adnak a fejlesztok olebe hogy onkent kossek magukat a platformhoz. Ez vegsosoron ez mindenkinek jo, mert beszalltak a versenybe.

Kb. ez az en meglatasom.

Na latod, ezert is jo ha nem minden egyes progit kulon-kulon kell portolni es javitgatni, hanem eleg a linuxos reteget foltozni-toldozni.

A microsoft beleolt egy csomo penzt es eroforrast hogy nehany kulcsfontossagu toolt portoljon/segitsen portolni. Most hogy letrehoznak egy linuxos reteget egybol tobb eszkoz futtathato es penzt+eroforrast csak egy helyre kell koncentralnia.

Ugyanarról beszélünk. Csak azt olvasva, hogy "bash coming to windows", nem egyértelmű, hogy ehhez minek a Canonical. De ha azt írnák, hogy ubuntu coming to windows, már érthető lenne.

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

Máshol már volt a cikkben a Cygwin, Msys.
Én meg a MobaXterm-re szoktam rá.

Annak a lokális terminálja is pont jó, ott
cd /drives/e/Tmp/
van.

MobaXterm:

uname -a
CYGWIN_NT-10.0-WOW hermelin 2.0.4(0.287/5/3) 2015-08-03 00:00 i686 GNU/Linux

free
total used free shared buffers
Mem: 16837283840 3576762368 13260521472 0 0
-/+ buffers/cache: 3576762368 13260521472

grep CPU /proc/cpuinfo | sed "s/$/ -- WOW/"
model name : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz -- WOW
model name : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz -- WOW
...

mount
C: on /drives/c type ntfs (binary,posix=0,user,noumount,auto)
E: on /drives/e type ntfs (binary,posix=0,user,noumount,auto)
...

:)

Nyilván meg lehet oldani, de nem egyszerűen, innentől pedig nem is éri meg, és nem is tudom mondani annak a pár windows felhasználó ismerősömnek, aki érdeklődne a linux után, hogy pár kattintással fel tudja rakni magának anélkül hogy aggódnia kellene particionálás meg ilyesmik miatt.

Először az volt, h linux az Azure-on. Aztán jött Miguel de Icaza "felvásárlása" a Mono-val, aztán az SQL szerver Linux-ra, most meg ez.
Összeesküvés elmélet?
Meg(v)eszik a Linux-ot?

mondjuk inkább ápr. 1 :)

Aztán jött
-a Xamarin ingyenessé tétele VS-ban, ide értve az Open-source fejlesztéshez ingyenes Visual Studio Community Edition-t is,
-a Xamarin Runtime Open source-olása,
-a Mono felkarolása és a hozzá kapcsolódó széleskörű patent promise.
Januárban pedig már láttuk, hogyan fordul linuxon a natív .Net Core kód függőségek nélküli ELF binárissá...

Üdv,
Marci

Igazán hívhatnák LINE-nak. Line Is Not an Emulator.

--
openSUSE - KDE user

Remek, a MicroFos feltalálta, hogy lehet a bash-t a windows sebességére lassítani és az erőforrás zabálását feltornázni.

Ez egy ostobaság, senki nem fog 3x annyit installálni, hogy egy ls-t ki tudjon adni.

De, sőt a blogbejegyzést is elolvastam. Csak értelmetlen az egész, és lennénk agályaim. Emlékszem olyanokra, hogy pl. a PHP windows-os portjában a hálózati részek nem mennek, meg a Postgresql azért nem volt sokáig Windows-on, mert nincs normálisan implementálva az UTF8. Kétlem, hogy ezek azóta elkészültek volna, így a rendszer hívások szintján történő fordítás elég sok helyen el fog vérezni. Plusz ugyanazon a vasamon a Windows kb 2x olyan lassan vánszorog mint egy Ubuntu, plusz folyamatosan forognak a ventillátorok. Én ezekre a személyes tapasztalatokra alapozom a véleményem.

Azonkívül az egésznek semmi értelme, max arra csinálták ezt, mert valami MicroFos vezető egyszer kiverte a hisztit, hogy az igazi geek-ek miért nem használnak windows-t. Én elárulom, nem azért mert nincs bash, hanem mert a diszk és memória kezelése a windows-nak egy rakás sz*r. És ez a csempés hulladék meg igazi user-riasztó.

"Emlékszem olyanokra, hogy pl. a PHP windows-os portjában a hálózati részek nem mennek"

Pont ezért lesz jó ez. Mert a kompatibilitási problémákat egy rétegnek lesz dolga megoldani, nem minden egyes portnak önállóan. Nem mondom, hogy nem lesznek, de azokat egyszerűbb egy helyen foltozni, nem?

"az egésznek semmi értelme"

Mondd ezt azoknak, akik node.js-t használtak volna akkor, amikor még nem létezett windows port. Megoldás akkor is volt, valahogy összetákolták talán cygwin-re, vagy futtatták virtuális gépben önálló linux alatt. Számukra nagyon jól fog jönni ez, meg mindenki másnak, aki Windows-t használ, de közben szüksége van linuxos eszközökre.