Dolgok, amelyeket úgy tűnik, hogy a Longhorn jól csinál

Címkék

Hans Reiser - a ReiserFS projekt kiötlője - küldött a minap egy érdekes levelet az LKML-re. A levélben arról ír, hogy a redmondi fejlesztők jónak látszó dolgokat próbálnak a Windows éveken belül megjelenő Longhorn verziójába beleépíteni. Felvetette, hogy esetleg a Linux kernelfejlesztőknek is lépniük kellene ebbe az irányba, nehogy egyes területeken lemaradjanak a fejlesztéssel. Ebből egy hosszú thread alakult ki.Reiser szerint a Longhorn fejlesztői arra keszülnek, hogy tranzakciós támogatást integráljanak bele az operációs rendszerbe. Minden XML-ben lesz, támogatást készítenek a filerendszerben való böngészhetőséghez. Az XML lekérdezés és böngészhetőség támogatása egy egységes formában fog megjelenni.

A levélre sok válasz érkezett. Sokak csak vaporware-nek nevezték a Longhorn ezen funkcióját. Ted Tso - veterán kernelfejlesztő - szerint nem biztos, hogy a Linux fejlesztőknek követniük kellene a windows fejlesztőket. Ha a windowsban megjelenik egy új funkció, akkor azt nem biztos, hogy nekik ugyanazon módon kell implementálniuk.

Kérte Reisert, hogy csak azért, mert egy vaporware sajtóbejelentést olvasott a Microsoft-tól, ne gondolja, hogy a.) az MS majd egy SQL optimalizátort fog beépíteni a Longhorn kernelébe, b.) hogy ha mégis megteszi, akkor a Linux fejlesztőknek követniük kellene a rossz példát, és ugyanazt kellene tenniük.

Az érdekes thread itt.

Hozzászólások

Dolgok, amelyeket ugy tunik, hogy a Longhorn NEM jol csinal.

Sokan írnak a Longhorn-ról, felkapott téma. Érdekes szerkezetű a dolog: például, a terminal server alapból fut, és a localhost-ról is ezen keresztül érheted el a felületet. Aranyos, ha leállítod a Term. Servert, akkor boot után vár, hogy leálljon, és megfagy, még Csökkentett módban sem hajlandó logint adni. Na ilyeneket biztos nem produkál egy Linux. Az install is érdekes van egy többszáz MB-os fájl rajta, nem kérdez, csak hogy melyik partíció legyen az install (minimum 3GB, !!!!).

Az ilyen dolgok nem követendő példák, ami viszon hiányzik a Linuxból, az az NTFS támogatás (rw, úgy mintha fat32 lenne).

User-Eye-Candy on 2,4 GHZ + 256 MB + 3 GB.

wince:~$ startx :)

Velemenyem szerint, azzal, hogy kivettek a kernelbol a beepitett webserver elegge vilagosan kifejeztek a fejlesztok, hogy nem akarnak rendszer fuggo dolgokat a kernelbe epiteni.

Wince: erdekes otlet, van valami otleted ra, amely biztonsagosan megoldana, hogy ha irunk az NTFS-re azt milyen felhasznaloval tegyuk? (Legutoljara a kernel make menuconfig -jaban maszkaval, ez volt az egyetlen kifogas az NTFS irasi resze ellen, amit olvastam - azota persze lehet megoldottak, vagy talaltak meg:)

Ha veletlenul nem lenne benne, es volna egy eppkezlab otleted ugy gondolom erdemes volna a kernel fejlesztoknek javasolni, mert nekem is hianyzik ez a szolgaltatas :) - sajnos nekem eddig nem tamadt ilyen otletem

Udv, Hijaszu

szerintem ez egyértelmű dolog: rendszeradmin (vagy hogy híjják azok a rootot).

majd ha vki linux alól akar elérni egy m$ partíciót, számít, hogy mik a wines jogosultságok?

egyébként nekem ez a szolgáltatás egyáltalán nem hiányzik, és azonnal dobnám a linuxot, amint a kernelfejlesztők m$ funkciók utánzásával kísérleteznének. ha hülyeséghez van kedvem, akkor le tudok win mögé is ülni, ha meg dolgozni szeretnék, akkor azt egy komoly rendszer alól tenném.

engem már az is megvisel, hogy újabban a configokat xml-ben tárolják, nehogy vi-jal olyan egyszerű legyen maszatolni...

Lehet írni az NTFS-t, a vanilla kernel-lel (alap, amit a kernel.org-rol letölthetsz), de csak megkötésekkel:

Nem fog változni a fájl mérete, csak kisebb fájlal írhatod felül, plusz chkdsk kell a win indulásakor. talán könyvtárat nem kozhatsz létre. szóval még gyerekcipő.

Nézz szét itt, ez nem hivatalos dolog, NOVARRANTI.

http://linux-ntfs.sourceforge.net/status.html#ntfsdriver

wince.

Az NTFS írás roppant egyszerűen megoldható linux alól.

Az ötlet a következő:

Létrehozol egy tetszőlegesen nagy fájl-t windows alatt az ntfs partición (bochs-ben van erre egy nagyon ügyes program: bximage). Ezek után reboot linux-ba. Bemountolod rw-nek az NTFS particiót (természetesen a limitációk, amik a fájlméret növelésére vonatkoznak megmaradnak). Berakod loopdev-be a fájl-t amit létrehoztál win alatt:

losetup /ahova/a/cucc/mountolva/van/a.fajl /dev/loop0

ezek után:

mkfs.vfat /dev/loop0

mount /dev/loop0 /ahova/csak/akarod

Innentől az NTFS-en levő tetszőleges méretű fájl limitációk nélkül írható. Windows-al keveset foglalkozok, de biztos ott is megoldható a fájl csatolása meghajtóként (ha nem, akkor mit is mondhatnék. ezt a limitációt az m$-nek kell kijavítania:)

Ennyi.

Kedves BaliHB!

Az NTFS irasaban, nem az az elvezet, hogy valamilyen uton modon atlopjunk egy file-t innet-oda (hisz akkor lehet, egy mindenki altal latott FAT32-es particiot is letrehozni ugyanazon a gepen, s milyen joooo), hanem az az elvezet, hogy az NTFS egy csomo olyan dolgot tud, amit a FAT32 nem. A leg kozerthetobb problema, ha NAGY file-okat akarsz atadni, esetleg van egy kiveheto vinyocskad, amire ra akarsz masolni egy NAGYobbacska file-t. Ugyanis egy DVD image keptelen felmenni a FAT32-re, hiszen, ott 2G (vagy mas hiresztelesek szerint: www.ntfs.com 4G a felso file-meret korlat...)

Szoval ezt nem tudod a te modszereddel megbuvolni...

Zsiraf

Az XML nem rossz tortenesen pl. config file-ok tarolasara (es vi-al is konnyen szerkeztheto) ez az irany tortenetesen jo a Loghornban, hiszen a jo oreg UNIX-os filozofia koszon vissza, azaz, hogy legyen human readable az aminek annek kell lennie.

De mondjuk ennek semmi koze a linux kernelhez, hisz alkalmazasokhoz kapcsolodik.

A "minden XML-ben" koncepcioja pedig teljes baromsag. Az xml parzolasi overhead altalanos esetben akar 100x!-is lehet.

Hali!

Biztos nagyon utalni fogtok a velemenyem miatt, de egy-ket dologhoz elofordulhat hogy jol johet a tranzakcios viselkedes. Szerintem nem az SQL szerverekre kell gondolni mert spec nem csak azok lehetnek tranzakciosak, hanem minden osztottan hasznalt eroforras.

Persze meg is bonyolitana a dolgokat, egy csomo dolgot nem lehet tranzakciosan gondolni.

Laci