Ve vývojové verzi Windows 10 dostupné v rámci programu Insider byl vylepšen Windows Subsystem for Linux. Nově má uživatel možnost ručně, pomocí příkazu (u)mount, připojovat a odpojovat disky/oddíly dostupné ve Windows. Dosud se disky připojily automaticky jen při startu subsystému. Také přibyla podpora přímého připojování síťových lokací. Ve stabilní verzi Windows se novinka objeví až někdy za půl roku s další velkou aktualizací.
(Zdroj: Slashdot)
Tak pokud udelaji dobry linuxovy subsystem, tak porad pobezi na desnych Widlich, takze bych se nebal. Ovsem oni ten subsystem delaji s Ubuntu a pochybuju, ze subsystem zalozeny na nem by byl nejlepsi na svete.
Ak je to robene stylom API vrstvy implementujucej POSIXove volania a na to nalezite upravenej implementacie standardnej kniznice (cca nieco ako cygwin, ale s tym, ze polka bezi scasti v kernel space), tak to bude mat stale ten fundamentalny problem, ze windows sucks at forking. To brutalne spomaluje shellskripty, ktore chrumu velke mnozstvo dat.
Chcete říct, že shell dodnes používá fork/exec (což je velmi nešťastná konstrukce) namísto třeba posix_spawn?
Výkon volání fork() je pokud vím problém hlavně pod Cygwin, protože ho emuluje pomocí Win32. NT kernel (a tedy i SFU a WSL) má nativní fork, ale nevystavuje ho pomocí Win32. Při implementaci WSL v kernelu navíc přibyly nějaké optimalizace ohledně forkování.
http://www.cygwin.com/cygwin-ug-net/highlights.html
https://channel9.msdn.com/Blogs/Seth-Juarez/Windows-Subsystem-for-Linux-Syscall-Translation?ocid=player -- čas cca 16:30
Něco na způsob FUSE lze nlézt třeba zde
https://github.com/dokan-dev/dokany
Nevím, jak moc dobře to ale funguje. Zkoušel jsem to použít pro připojení SSHFS, ale nepodařilo se (asi ne vinou přímo Dokany, ale nějakého SSHFS doplňku, který se nedokázal přenést přes to, že jeho oblíbené písmeno disku je již zabrané).
Jinak souhlasím, psát souborové systémy (což jsou ovladače) ve Windows není sranda. Sice mají celkem fajn API pro filtrování operací nad FS (FS minifilters), ale pro FS nic takového zjednodušujícího není.
http://www.swish-sftp.org/ - nějak funguje, ale často zamrzá explorer.exe, někdy na chvilku, někdy na docela dlouho. Připojit se aniž by něco zamrzlo vyžaduje správnou sekvenci klikání na správná místa, i když ani to není 100%.
https://github.com/Foreveryone-cz/win-sshfs - funguje perfektně, i když místo integrace do exploreru se ovládá programem sídlícím v tray. Můžu jedině doporučit :)
Jo, jo - zlaty kernel development na Linuxu :-)
Kdysi kolem roku 2002, kdy jeste Lotus Email (ci jak se to jmenovalo) neumel pracovat s cipovou kartou, jsem dostal za ukol napsat pod WinNT neco jako FUSE - kernel FSD 'trampolinu' ktera se na kernel stranu tvarila jako disk, ale mela druhy konec do user space, kde bezela aplikace/service, ktera pres PCSC pracovala s cipovou kartou, delala dialogy na PIN a podhazovala data te FSD strane ve formatu souboru der/p12/ ......
Ano, 'otevreny' Microsoft - IFS DDK nebylo v te dobe soucasti standardniho DDK nebo MSDN, ale neco navic, co se asi mozna i dalo nekde v CR sehnat - takze podpora ze strany M$ zadna ::-(
Vetsinu jsem tedy napsal s pmoci open re-implementace ntifs.h od 'Bo Brantén'. Dokonce jsem si k tomu koupil i original knihu 'Windows NT File system Internals' od Rajev Nagaar :-) A diky za kernel developers forum OSR.
A cela ta interakce v kernelu s 'Cache Managerem', 'Virtual Memory Manager', 'FastIo' a dalsimi komponentami.... - no proste hruza.
Ono to fungovalo celkem dobre, ale nedej boze, kdyz se na ten disk pokusil pristoupit explorer.exe - jak se ho snazil 'prosmejdit' a najit 'zname' soubory v jednotlivych/vsech adresarich (desktop.ini) - bylo to zajimave sledovat pres DbgView, co vsechno s tim 'diskem' dela ...
Jojo, naštěstí jsem ty časy, kdy IFS nebylo součástí DDK/WDK nezažil. Teď se stačí podívat na "open source" ovladače, které jsou součástí WDK (fastfat, cdfs), aby bylo jasné, že se fakt o triviální úkon nejedná.
Nevím, co přesně jste měl za požadavky, ale pokoušel bych se psaní vlastního FS vyhnout, co by to šlo (např. vytvořit "virtuální disk", který by emuloval datové struktury nějakého FS, popř. ve spolupráci s FS filterem). Ale jednoduché by to ani tak nebylo.
Umí ještě ReFS, UDF a exFAT. Plus si můžete doinstalovat co kdo napíše. Existují implementace ext2/3/4, Btrfs, ReiserFS, HFS atd., open i proprietární, v různém stavu.
Windows nemá out-of-the-box nic jako FUSE. Můžete psát kernelové FS drivery, případně použít reparse points (přístup do dané části FS stromu vyvolá váš kód, pak si můžete dělat co chcete) a filter drivery (můžete třeba filtrovat, šifrovat, nebo podstrčit jiný obsah). Obdobou FUSE je projekt Dokan (nabízí i nějakou kompatibilitu s FUSE), případně komerční CBFS.
https://en.wikipedia.org/wiki/Dokan_Library
https://www.eldos.com/cbfs/
Upřímně nevidím moc důvodů pro funkcionalitu typu FUSE. Výkon je nutně horší než u kernelové implementace, a osobně bych se spíš soustředil na tom mít (klidně jeden) spolehlivý FS, než mít hromadu polo-funkčních. Možná pro čtení cizích FS, ale tam je stejně vždycky spousta problémů s právy, znakovými sadami, neimplementovanými features atd.
Já narážel spíš na klasický unixový zvyk mít jeden obecný FS, další který má žurnálování, další který umí šifrovat, další co umí kompresi atd. Koukněte se na Solaris: primární FS je ZFS, legacy UFS, pro interoperabilitu pak FAT, ISO9660 a UDF. Na Linuxu jsou z těch běžnějších FS Btrfs, exFAT, ext3, ext4, F2FS, HFS, JFS, NILFS2, NTFS, Reiser4, ReiserFS, VFAT, XFS a ZFS, plus k tomu hromada méně běžných (encFS, eCryptfs, SquashFS, ...). Považuji to za tříštění sil.
Ale no tak. Na Linuxe je primárny btrfs a ext4, okrajovo reiserfs, všetko ostatné je pre interoperabilitu, prípadne rôzne špecifické použitia. *FAT/NTFS je pre microsoftie systémy a flashky, HFS je z Mac-ov, xfs je z IRIXu, JFS z AIXu, ZFS z Solarisu, atď.
Vaša schopnosť prezentovať podporu konkurenčných formátov ako nevýhodu je skutočne obdivuhodná.
Já snad netvrdil, že podpora dalších FS je nevýhoda. Jen mi uniká, proč investovat úsilí do vývoje tolika FS. Například vývoj Btrfs začal někdy v roce 2007, a ani po deseti letech se nedá považovat za stabilní. Kdyby se místo na desítku FS vrhly prostředky řekněme právě na Btrfs, tak mohl být dávno hotový ve špičkové kvalitě. A jistě by zbyly zdroje třeba na implementaci plánovaného transparentního šifrování souborů, případně na portování na další platformy.
Lael Ophir 21.4.2017 17:15 "Považuji to za tříštění sil."
tuto frazi pouzivaji vyhradne trollove nebo hlupaci, v pripade zamestnance PR oddeleni Microsoftu jde o kombinaci obojiho... kdokoliv soudny a racionalne uvazuji clovekby takovou kravinu z ust/klaves nevypustil...
realita je takova ze ext4 je primarni filesystem, btrfs je FS s modernima vlastnostma ve vyvoji
ext3 - predchozi verze ext4, to je jako by nekdo psal ze "NTFS 1.0, NTFS 1.1, NTFS 1.2 (zname tez jako NTFS 4.0), NTFS 2, NTFS 3.0 (zname tez jako NTFS 5.0), NTFS 3.1 (zname tez jako NTFS 5.1, NTFS 5.2, NTFS 6.0)"
exFAT, HFS, JFS, NTFS, VFAT - filesystemy kvuli kompatibilite (chapu ze to slovo Microsoft nesnasi protoze preferuje vendor lock-in)
XFS, ZFS - jednak kvuli kompatibilite, druhak jsou jejich fanousky pouzivane pro specificke vlastnosti
F2F2 - jednak kvuli kompatibilite, druhak je to specificky filesystem urceny specialne pro sd/flash, narozdil od ve Windows pouzivaneho totalne hloupeho VFAT vychazejici v podstate z potreb floppy a msdosu...
encFS, eCryptfs - jde o virtualni vrstvu pro sifrovani kterou lze kombinovat s filestemem dle potreby, ve Windows je podobne v podobe s NTFS pevne svazane(takze ta horsi varianta) sluzby "Encrypted File Service"
SquashFS - jde o komprimacni format/filesystem pouzivany primarne na readonly filesystem, at jiz LiveCD/LiveDVD/LiveUSB/LivePXE) tak pro embedded systemy... podobne jako Microsoft pouziva (ale hure/hloupeji) svuj (dalsi) file-disk format WIM...
Linux má 5 primárních, aktivně vyvíjených filesystémů - Ext4, Reiser4, BtrFS, XFS, ZFS (OpenZFS).
To se mi opravdu zdá jako zbytečný luxus.
Slovem "primární" myslím systém zamýšlený (doporučený, optimalizovaný) jako root file system; tedy primárně pro pevné disky, k uložení a běhu systému samotného, aplikací a (potenciálně terabajty) uživatelských dat.
Zrovna jsem včera instaloval openSuse Leap 42.2 a baflo to na mě XFS nebo BtrFS jako výchozí.
Chystám se na Ubuntu, tak jsem zvědavý s čím ten na mě vybafne. Nebude to náhodou ZFS? Prý to mají od Oracle CDDL licencované. Nebo se toho také v rámci letošního velkého "jarního výprodeje" hodlají také zbavit?
Za tu roztříštěnost, v tomto případě, kupodivu, nemůže linuxová komunita, jako spíše historie, korporátní zájmy a komerční Unixy. BtrFS začal Oracle, ZFS je od SUNu, XFS od SGI, Ext původní linuxový FS a Reiser je (primárně) komunitní počin.
Mimochodem, s FS má problémy i Microsoft. Jejich ReFS (Resilient File System, neplést s ReiserFS!), the next generation FS :), zamýšlený nástupce NTFS, ani po letech vývoje se svému předchůdci plně nevyrovná (asi něco jako bylo KDE4 proti KDE3 většinu svého aktivního vývoje). ReFS je sice součástí Win od 8.1 ale není normálně aktivován.
Linux má 5 primárních, aktivně vyvíjených filesystémů - Ext4, Reiser4, BtrFS, XFS, ZFS (OpenZFS).
To se mi opravdu zdá jako zbytečný luxus.
Co se zda tobe jako luxus, je podruzne. Dulezite je, co chcou firmy platici vyvoj jednotlivych FS.
Pricemz tvuj vycet je mimo.
Ext4: konzervativni vyvoj unixovych FS, ktery se snazi drzet a zaroven zbavit koncepci z davnych casu. Je to slepa cesta vyvoje, ale protoze stabilita a rozumny vykon, tak se stale drzi.
Reiser4: to vazne nekdo realne nasazuje?
BtrFS: pokus o moderni FS, ale udelat obecne pouzitelny FS na zelene louce je prekvapive hodne prace.
XFS: osvedceny a vykonny FS pro enterprise reseni, prevzany z IRIXu, takze "skoro bez prace"
OpenZFS: ono uz je to ve vanille?
Takze kdyz si to prepocitas, mas tu tri pouzitelne souborove systemy, z toho dva koncepcne zastaravajici, jeden v pokrocile fazi vyvoje, jeden na pul chciply a jeden ani neni ve vanille. Vazne ti to prijde jako nejaky extra luxus?
nastesti diky licenci GNU by Microsoft to nemohl postavit pod EULU a sebrat lidem zbytek jejich svobod, nicmene stejne by to byl system na h0vno, tim ze by MIcrosoft do nej implementoval sber dat, funknce "vime nejlip co chcete a nic jineho vam nedovolime" a podobne prasarny...
dalsi vec samozrejme je to ze GNU/Linux Desktop je pouzitelny jiz velice dlouho, pro pokrocile uzivatele uz od minuleho stoleti, pro ty mene pokrocile (~99% z nich) poslednich 5-10 let
Proč bych měl kompilovat BSD pro telefon? Psal jsi, že Android není svobodný, protože má non-GPL libc, díky čemuž tam údajně nemůže běžet nic cizího*. Tak jsem se ptal, v čem je BSD méně svobodné? Ta libc je pod BSD licencí. Čekal jsem, že jako expert na uzavření Androidu budeš vědět, že mluvím o licenci toho libc a ne o úplně cizím systému.
* což je nesmysl samo o sobě, ta libc podporuje všechny POSIX funkce
BSD (licence) je mene svobodne nez co?
Dost sverazne vyklady. Psal jsem, v reakci na to, ze "licence GNU" (GPL) je jakousi zarukou svobod, ze GPL je jadro, libc uz je non-GPL _a_ ze Anroid je !@#$% i ve srovnani s Windows; trik s libc je pekny, ale to by asi nestacilo.
Bezne linuxove (typicky glibc) programy tam nepobezi, ledaze jsou staticky zkompilovane nebo rekompilovane s bionic libc (pricemz to, ze dve ruzne libc implementuji stejny POSIX, neznamena, ze jsou zamenitelne).
S kompilovanim pro tefelon jsi zacal ty. Oba ale vime, ze to neudelas bez ohledu na dostupnost zdrojaku, tudiz ten argument, o ktery se patrne pokousis, vyzniva do ztracena. Schvalne, co mas za mobil a co na nem mas?
Běžné linuxové programy zkompilované pro glibc z Debianu bez rekompilace nepoběží ani na glibc z Gentoo. Takže tenhle argument je nesmyslný.
Psal jsi: ke GPL kernelu non-GPL libc, aby nahodou nefungovaly cizi aplikace (ono to tu není tak těžké dohledat ;), což je hovadina. Už třeba proto, kolik cizích aplikací pro Android je.
S těmi svobodnějšími Windows jsi to tedy myslel jak? Zdrojáky nejsou, upravit je nemohu, zkompilovat pro svůj telefon či počítač (bez toho, abych s MS podepsal NDA) taky ne. Nebo snad víš o něčem jako Cyanogenmod nebo MIUI založeném na Windows?
Argument spociva v tom, ze pokud dve "distra" pouzivaji jinou libc, rekompilovat musis (naproti tomu u dvou dister se stejnou libc, bez ohledu na Gentoo, ne ntune), a pokud tak cinis (byt, pravda, zrovna ty vzbuzujes dojem, ze necinis), narazis na extra problemy, coz je mozna vedlejsi, ale jiste vitany efekt izolace userlandu od (L)GPL.
S temi Windows jsem to myslel tak, ze...nejprve reknes, co mas na tom mobilu, abychom si dlouze nepovidali o stahovani, upravovani a kompilovani, a pak z tebe nevylezlo, ze to mas, jak to prislo z tovarny, jak nejake Widle.
Na jaké extra problémy narazíš při kompilaci pro jinou libc? Jak se tyhle problémy liší od typické tuny problémů při portování na jinou distribuci (jiný balíčkovací systém, jiné umístění knihoven, systemd × upstart × sysvinit, SELinux × AppArmour, …) či jen při kompilaci pro jinou architekturu (Android je hlavně ARMv7 a AArch64)?
Docela jsi mě rozesmál. Ve zdrojácích Androidu se hrabu prakticky každý týden (protože nativní rozhraní pro Android jsou dost mizerně dokumentované a ve starších API to často funguje jinak, než je popsané) a vyvíjím custom firmware s proprietární systémovou službou, takže o tom trochu nějaké povědomí mám ;) Chtěl bych vidět někoho, kdo tohle může říct o těch Windows :P
