Új Linux disztrók érkeznek a Bash/WSL-re a Windows Store-on keresztül

Microsoft, Windows

Multi-distro

A Microsoft részéről Rich Turner a napokban bejelentette, hogy folytatják a korábban megkezdett együttműködést a Canonical-lal, illetve újabb Linux disztribútorokkal - Fedora, openSUSE - működnek együtt annak érdekében, hogy Linux terjesztéseiket a Windows Store-ba betehessék.

Részletek a bejelentésben.

( mrceeka v | 2017. 05. 13., szo – 19:44 )

trey, a fiad a leendő Windows 10 S-én még válogathat is majd a környezetek közt :D

Üdv,
Marci

Hibaigazítás: nem lesz rajta Linux
Elnézést.

Üdv,
Marci

Hibaigazítás: "Tegnapi számunk hátsó oldalán tévesen jelent meg a nutriatelepről készült fénykép aláírása. A helyes aláírás a következő: HÁROM JÓL FEJLETT NUTRIA. Helytelen tehát az előző aláírás, hogy a NUTRIATELEP HÁROM VEZETŐJE."

( uid_16313 | 2017. 05. 13., szo – 20:01 )

Még mindig nem értem, miért kell nekem Windows 10 ahhoz, hogy linux-ot futtassak?

--
robyboy

Van az embernek egy megszokott környezete ahol kényelmesen érzi magát, szokták ezt sok helyen desktopnak csúfolni. Tudod ez az amit nem túl óvatosan a cégetek 10 évente újragondol és rinyálnak miatta (nem kell aggódni ugyanúgy van ez gnome-shell/gnome) esetén. Mindenesetre a Linux Desktop nem ér véget ott hogy tud shell-t futtatni..

( Gaab | 2017. 05. 13., szo – 22:30 )

...Es meg mindig nem lehet elrakni mashova a rootjat az appdata\local\blabla alol.

Ha máshol lenne, nem a 120GB-s rendszer particiót enné, hanem a 2TB-os data+egyéb vinyót.
Mondjuk a meghajtó mountolása mappába nem ördögtől való.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

"csak nekem teljesen alap az, hogy lehetoseget biztositsunk a juzernek, hogy hova szeretne telepiteni valamit?"
Alapni alap lenne, de Windowson nem igazán az.

Ezt a rugalmasságot ugyanis nem (csak) a WSL, hanem a Windows általában nem biztosítja, sajnos.
Úgyhogy amíg a \Users mappa helyét nem válogathatom meg, hanem a profilkönyvtáron belül irányítgathatom át a mappákat kézzel (aztán az alkalmazásokat vagy érdekli-vagy sem!), addig nekem sokkal kisebb fájdalom, hogy hol a WSL root (ami ráadásul nem olyan nagy helyet foglal)...

Üdv,
Marci

aztán az alkalmazásokat vagy érdekli-vagy sem!

Számomra ez a legfájdalmasabb az egészben. Mi az, hogy az oprendszer nem tud valamit úgy elfedni az alkalmazás elől, hogy az ne is tudjon róla? Épp, mint a globbing. Nem az alkalmazásnak kell feldolgoznia például a *.*-ot, hanem a shellnek, de Windows-on valamiért csak remélhetjük, hogy két alkalmazás hasonlóképp emészti ezt meg, amit literálisan megkapott.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

off

Vicces. Egy példát akartam írni, mire aztán rájöttem, nem is lenne igazán jó példa, mert a hardcoded ostobaságra valóban nincs ellenszer. (Lehet, zavarosan fogalmaztam. Te írtad helyesen, az a programozó az ostoba, aki effélét elkövet.) Viszont, miközben a példához gyűjtöttem a konkrét infót, észrevettem, hogy nem megy a profile-sync-daemon. A program maradt a régi, de a bash újabb, s elhasalt ugyanazon a scripten. Kijavítottam, most működik, szerintem bugreportolni fogom. :)

Volt egy ilyen kifejezés:

${#DIRArr[@]##*/}

Picit túltolták. Az első # nélkül még értelmes, hiszen előállítja a tömbből az elemek utolsó / utáni részeit szóközzel szeparálva. Viszont, amikor ezt meg kell számolni, akkor felesleges az elemek leszabdalása, az elemek számosságát a ${#DIRArr[@]} kifejezés adja vissza. Az eredetit a régi bash megette, de az új már egy bad substitution üzenettel honorálja azt.

Valami olyasmi akart lenni a példám, hogy nekem a / (SSD) alá van mount-olva a /home (HDD) és a /var (HDD), a /home alatt van valahol a .mozilla, ami egy symlink a /var alá, de valójában az nem is a /var, mert oda bind mount-oltam az SSD-m egyik filerendszerének egy könyvtárát. S ha ez nem volna elég, alatta van a firefox profile, ami viszont egy újabb symlink valahova a /tmp-ben található könyvtárra, ami meg tmpfs, tehát RAM és swap. Viszont ezt a szörnyű ámokfutást a böngésző úgy éli meg, hogy valahol a $HOME-ban van neki egy profilja. :)

Mindezt azért csináltam így, mert azt szerettem volna, hogy a hatalmas böngésző profil másolása gyors legyen RAM-ba, tehát SSD-ről történjék, ne pedig HDD-ről, mert különben odavész a rövid boot time. A psd meg azért kell, hogy a böngésző gyors legyen, s ne generáljon adatforgalmat az SSD-re.

Amúgy van tovább is, mert a RAM disk valójában egy overlayfs az SSD fölött. Jó, hát elvoltam, na! :D

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

nem annyira off ez.
Pontosan megmutatja a felfogásbeli különbséget.
GNU/Linuxéknál a várható impacttól függetlenül dobják a visszafelé kompatibilitást, ha meg nem működik a szoftvered, akkor így jártál, oldd meg magad.
Míg a Microsoft igyekszik ügyelni a visszafelé kompatibilitásra, pont azért, mert a vállalati ügyfeleknek nem mindegy, hogy a belső ügyviteli rendszerük, amit egy már nem működő 3rd party cég készített, működik-e vagy nem.
Persze van, amikor dobni kell a kompatibilitást (vagy épp a támogatást), de amíg csak lehet, tartani kell.

Emiatt sem megy igazán a vállalati szférában a Linux, és pont az ilyen kompatibilitási szarok miatt kellenek a konténerek. Mert valamelyik szoftvernek frissebb libc kell, az meg szentségtörés, hogy egyszerre több libc legyen a rendszerben (Windows alatt ez tök alap).

Amellett, hogy igaz, amit írsz, úgy érzem, a Linux és alkalmazásai általánosabban kezelnek dolgokat, talán kevésbé nyúlnak át rétegek felett, s így hiába forgatnak fel egy-egy alrendszert, attól még a legtöbb program működőképes marad. Pulseaudio-nak is lett egy alsa-lib intarface-e, hogy menjenek azok az alkalmazások, amelyekbe sohasem implementálják a pulse illesztést. Vagy a példám a filerendszerek kezelésének végtelen rugalmasságával. Az alkalmazásnak fogalma sincs arról, hogy ez hogyan van alul összeszögelve. Kernel majd megoldja, alkalmazás meg ugyanazt az elérési utat látja.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ugyan bugreportoltam, küldtem patch-et, de ez elárvult csomag, Fedora 23-hoz volt utoljára, így arra számítok, nem lesz visszhangja a hibajelzésemnek. Mivel shell script, működik ez, magamnak ki javítottam, frissítés meg aligha fogja elrontani, mert várhatóan nem lesz.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"Mi az, hogy az oprendszer nem tud valamit úgy elfedni az alkalmazás elől, hogy az ne is tudjon róla?"

A Microsoft néha tán túlzottan is erősen őrzi a visszafelé kompatibilitást, gyanítom, hogy ennek a következménye a fenti tünemény is.
A másik fele a kérdésnek -- gelei-vel egyetértve -- a fejlesztők oldalán van. Egy Linux sem tud mit kezdeni azzal, ha egy program a /home/$USER alatt akarja a felhasználó filejait kezelni.

Üdv,
Marci

Az vitán felül áll, hogy lehet csökönyös programot írni, ami aztán nem foglalkozik holmi környezeti változókkal, olyan apróságokkal, hogy hol van a felhasználó saját alkönyvtára, s effélék. Bár erre meg azt mondom, állítólag a pékeknél munkaerőhiány van, az ilyen ne programozzon. Bár ki tudja, a kenyeret is biztos elégetné. :(

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"Egy Linux sem tud mit kezdeni azzal, ha egy program a /home/$USER alatt akarja a felhasználó filejait kezelni."

A Linux ad eszközt a probléma megoldására/workaroundolására? Van valami komplexitás a probléma mögött, hogy az nem elég jó, ha átbindelem az user profilt oda, ahol az alkalmazás hiszi, hogy megtalálja?

"Hogy jön ide a workaround lehetősége"

Felvetettél egy problémát, azt mondtad, hogy a Linux nem tud mit kezdeni vele. Erre írtam, hogy igen is van a Linuxban eszköz rá.

"mi az a bindelés?"

A bindelés, szebben bind mount pongyolán fogalmazva annyit tesz, hogy adott mappát valahonnan becsatolsz a fájlrendszerbe máshova. innentől olyan, mint ha ott is létezne ahova csatoltad. Ha egy alkalmazás a home alatt keresi az user mappáját, oda lehet bindelni, és fog rendesen működni. Hacsak... nos, nagyon speciális esetek biztos előfordulhatnak, ezért is említettem komplexitást.

Szerintem nem is kell mount, egyszerű link megoldja.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988 @ Proharder Fórum

"azt mondtad, hogy a Linux nem tud mit kezdeni vele"

Azt mondtam: "sem". És így is van: ha a /home már másra foglalt (és emiatt nem a /home alatt laknak a felhasználók), akkor ez a workaround fabatkát sem ér.
Sem bind mount-tal, sem symlinkkel, sehogy.
Ahogy a hasonló eset Windowson sem workaroundolható.

Félreértetted a mondandómat: nem a Linuxot szóltam le, hanem annyit állítottam, hogy a fejlesztői trehányság-műveletlenség-elavult módszerek alkalmazása az OS platform oldalán tetszőleges nehézséget is okozhat. (Amiből nyilván van workaroundolható is, meg nem is - platformtól függetlenül)

Üdv,
Marci

"akkor ez a workaround fabatkát sem ér."

Ezt légyszi elaboráld, biztos én nem tudok valamit, de nem igazán értem miért nem ér fabatkát sem.

"a /home már másra foglalt"

Ez alatt mit értesz? Nehezen képzelek el egy olyan rendszert, ahol a jozsi nevű felhasználó lakik teszemazt /jozsi alatt, és emellett a /home/jozsi is használva van valamire. Ha mégis így lenne, akkor tényleg gáz van, mert a mounttal elfeded a /home/jozsi tartalmát a /jozsival. Egyéb esetben viszont nem látom miért ne működne.

"a fejlesztői trehányság-műveletlenség-elavult módszerek alkalmazása az OS platform oldalán tetszőleges nehézséget is okozhat"

Egyetértünk, az ilyen dolog gáz.

Egyébként nagyon rá vagy állva, hogy mindent támadásnak vegyél a fórumon. Feldobtál egy problémát aminek a megoldása triviálisnak tűnik linux alatt, próbáltam kitalálni mért gondolod annak (simán lehet az, hogy én nem értek eléggé a lovakhoz) de inkább terelsz :) Oké :)

Reálisan el tudom azt képzelni, hogy egy szinttel lejjebb vannak a felhasználók, például:

/home/fejlesztes/jozsi
/home/gyartas/karcsi

Ilyenkor lehet csinálni egy symlinket /home/jozsi -> /home/fejlesztes/jozsi formában, vagy mkdir /home/jozsi; mount -o bind /home/fejlesztes/jozsi /home/jozsi. Probléma akkor van, ha a különböző területeken azonos nevű felhasználók vannak, de mivel a login name eltérő, csak nem csinálták azt, hogy ennek ellenére a directory név azonos.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ez az én véleményem. Baj? Tudom, Linuxon is van olyan, amikor egyfajta globbingot az alkalmazás dolgoz fel, de ott ez indokolt. Például az

rpm -qa kernel\*

parancsban literálisan adom át a csillagot, mert ez az rpm számára glob. Úgy értve, az rpm adatbázisból túrja ki, ami úgy kezdődik, hogy kernel, s utána bármivel folytatódik. Itt nem volna jó, ha a shell kifejtené az aktuális alkönyvtárban található kernel* file-okat. Ha nincs ilyen, az mázli, mert akkor a shell szintén literálisan adja át a csillagot, ellenben ha van, akkor azt megkapja az rpm, s ha van olyan nevű csomag az rpm adatbázisban, listázza azt, ha nem, akkor pedig nem, de várhatóan kevesebb csomag lesz listázva, mint ami az rpm adatbázis van, hiszen a rpm adatbázisban és az aktuális alkönyvtárban szereplő nevek halmazának metszete lesz az eredmény.

Ettől függetlenül egy rm, cp - del, copy - esetében szerintem igen is praktikus az, ha a shell bontja ezt ki, s nem maga az alkalmazás.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( Aadaam v | 2017. 05. 13., szo – 23:16 )

Ha ez elterjedne az eléggé kinyírná a kommersz desktop appok linux piacát és ezen keresztül a linux desktopot.

Én azért álltam át anno OS X-re mert tudtam, ott vannak jó kommersz appok, cserébe ha valami hiányzik a linuxból, indítok egy X-et oszt szevasz, a legtöbb dolog lefordul rá, és alapból van rajt egy unix env.

Namost az hogy Windowson is vannak kommersz appok az senkinek nem meglepő, viszont ha tömegesen kezdenék a WSL-t használni az emberek, akkor a Skype meg a Spotify feltenné a kezét, minek neked linux kliens, rakj fel egy Windows-t meg egy WSL-t oszt hadd szóljon.

Így se nagyon van sok és jó closed source app arra a platformra, de így lehet hogy nulla lenne, amit Pistike összehekkel a feltört API-kból, az van...

Attól még továbbra sem lesz ingyen a Windows. Tehát aki az oprendszer ára, s nem utolsó sorban az EULA elfogadhatatlansága (privacy!) miatt nem használt eddig Windowst, az továbbra is éppen ezért nem fog, hiába került fel a Windowsra egy WSL. Jó, ott van, és? Attól az még egy Windows marad minden kínjával, ideértve a váratlan frissítéseket, reboot-okat, tiltott, de visszamászó csomagokat, s így tovább. Szerintem éppen ugyanannyi embernek lesz szüksége linuxos Skype kliensre, mint eddig.

Nem is igazán értem a gondolatmeneted. Windowsra eddig is volt Skype kliens. Most, hogy van Windowsra WSL, hirtelen miért érezném úgy, hogy a Fedora 26 helyett Windows 10-nek kellene lennie a gépemen? Valahogy nincs bennem efféle késztetés.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Igen, értjük, hisztizni kell, hogy jajajaj, fúj Windows. Nem te vagy a célközönség, haladjunk.

A valós célközönség oldaláról nézve meg: aki heterogén környezetben dolgozik, és használ Windowst és Linuxot is vegyesen, annak végre nem kell virtualizált szarokkal szenvednie, csak, hogy megkapja azt az userlandet, ami a munkájához szükséges. Ugyanis bármilyen meglepő, az userek 98%-ának édesmindegy a kernel, ami a rendszer mögött megy és az az érdekes számára, hogy az userland mit nyújt.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Szerintem nem nagyon figyelted, mire reagáltam. Nem az volt a lényeg, hogy szeretjük a Linuxot, a Windowst meg nem annyira, hanem azon a vélelmezésen tűnődtem, mely szerint a WSL keresztbe fog tenni a zárt linuxos alkalmazásoknak. Megvallom, én nem látok efféle összefüggést.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( saxus | 2017. 05. 14., v – 02:59 )

Szóval előbb lesz Debian/kWindows, mint Debian/Hurd?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( taklertamas | 2017. 05. 14., v – 08:04 )

Apró, jelentéktelen észrevétel, flamebite, whatever:

Mindhárom disztró minialkalmazás vagy miaszösz alkalmazásikonja egy Ubuntu logo.

Manjaro KDE 17.0.1

( dejo v | 2017. 05. 14., v – 11:11 )

A Microsoft milyen lelkesen szolgálja ki a Linuxot is használó ügyfeleit. Teheti, hiszen a Linux nyílt forrású és szabadon felhasználhatja, a GPL betartása mellett.
De mikor jut el odáig, hogy ugyanilyen Windows alrendszer beépítését teszi majd lehetővé a Linux rendszereken? Vagy legalább azokon a Linuxokon, amelyeket ő is implementál a Windows alá.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Aki a beta terméket éles munkára használja, nyilván alapos okkal teszi.

Amúgy te tulajdonképpen miről beszélsz? Mert ebben a szálban erről van szó: "De mikor jut el odáig, hogy ugyanilyen Windows alrendszer beépítését teszi majd lehetővé a Linux rendszereken?" (Nem mintha khiraly-t érdekelte volna... :( )

Üdv,
Marci

> Aki a beta terméket éles munkára használja, nyilván alapos okkal teszi.
Ebben egyetértünk. Remélem nem kerülünk be hétvégén a hírekbe. :D

> Amúgy te tulajdonképpen miről beszélsz?
Tulajdonképpen fejlődik a téma, megvan a kapocs, nézd csak: Dejo kvázi hiányolta a Microsoft saját Wine implementációját -> Te írod hogy nézze meg az MSSQL for Linuxot, nyilván utalva arra, hogy egy user modú NT kernel fut a dolog mögött -> khirály bedobta, hogy kvázi csak játszani jó vele -> megkérdezted hogy miért másabb ha munkára vagy demora használja -> jöttem én, próbálva utalni arra (jó, ez nem volt túl közeli), hogy ami opcionálisan használható saját, kísérletezgetős környezetben, az már jó eséllyel demozáskor meghal, de ha mégsem és ki lesz élesbe engedve, akkor garantált a sev1. Ez a különbség. Válaszoltam a kérdésedre.

Elvittük a szálat kétségtelen, de erről beszélünk. No nem mintha te olyan ontopik lettél volna. :)

No de hogy visszakanyarodjunk az eredetihez: felmerült bennem a kérdés, hogy van-e elérhető dokumentáció arról, hogy milyen szolgáltatásokat nyújt ez a kiskernel az MSSQL-nek és ha ezek más alkalmazások számára is használhatóak, akkor mondjuk Wine-on keresztül hívhatóak lennének-e? Alapvetően ugyanaz foglalkoztat engem is, mint Dejot.

"milyen szolgáltatásokat nyújt ez a kiskernel az MSSQL-nek és ha ezek más alkalmazások számára is használhatóak, akkor mondjuk Wine-on keresztül hívhatóak lennének-e?"

A szolgáltatásokat én nem ismerem pontosan, ezt javaslom olvasgatni: https://webcache.googleusercontent.com/search?q=cache:kFbvm2NRQ6kJ:http…
A wine nekem ennek a konkurrenciájának tűnik és igencsak eltérő elvek mentén működik, ezért kétlem, hogy ez megvalósulna.
Inkább elvileg érdekes ma még csak, hogy ez a későbbiekben akár más Win32 holmik futtatását is lehetővé teheti Linuxon.

Üdv,
Marci

0. step:

Read the EULA.

Majd szoljatok ha meg is lehet venni eles hasznalatra.

Egyebkent meg altalaban az MSSQL es a .net egyutt jar...

Szoval az MSSQL-lel onmagaban nem vagyok kisegitve...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Ebben a szálban erről van szó: "De mikor jut el odáig, hogy ugyanilyen Windows alrendszer beépítését teszi majd lehetővé a Linux rendszereken?"
Ki mondta, hogy ez kész termék?
Ki beszélt arról, hogy éles használatra alkalmas?
Ki mondta Neked, hogy nincs .Net Linuxon?
Tkp miről beszélsz? :)

Üdv,
Marci

Én neked válaszoltam, és konkrétan erre reagáltam:
"""
Nézz csak utána, hogyan működik az SQL Server for Linux és lepődj meg! ;)
"""

Ha a szálban feljebb szerettem volna reagálni egy másik embernek,
akkor neki válaszoltam volna.

> Ki mondta Neked, hogy nincs .Net Linuxon?
> Tkp miről beszélsz? :)

Én konkrétan megnéztem egy MSSQL+.Net-ben írt program portolásának lehetőségét.

Szerinted van *támogatott* út a .Net linuxon való futtatására?

Vagy csak úgy be-bedobunk valamit még pluszba, hogy egyre több mindenről beszéljünk?

Legutoljára, amikor néztem, az MSSQL for linux demo volt, amit EULA-val el kellett fogadni, és csak úgy futtathattad
(telepítettem és játszottam vele egy napot).

Azóta nem néztem, ez igaz. Változott valami?

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....