Az Etch kiadásának fő hátráltatói

Akkor mar a legdurvabb: "fájl". Teccikerteni...:] Legyen mar akkor inkabb "állomány", szoval ha nem letezne ra magyar szo, akkor aszondom, hogy ize, de igy... a byte az tenyleg huzosabb...

Atyaég, és a flopi is ott figyel... tényleg le vagyok maradva :(
Már csak abban lehet bízni, hogy a hajlékonylemezes meghajtók lassan kikopnak a használatból és nem lesz ideje elterjedni ennek a "remek" szónak :). A csiphez viszont úgy tűnik, muszáj lesz hozzászokni.

a két kötőjel nem ugyanaz! a dselectet nézve a legfrissebb etch verzió: 2.6.18-7, de ez nem a 7-es series file alkalmazását jelenti, valóában a 3-as series filet, de pont ezt írtam visszább ...
de egyébként ez látszódik is a filenévből!
pl.: linux-image-2.6.18-3-vserver-amd64_2.6.18-8_amd64.deb, azt jelenti, hogy a 2.6.18-as debian linux kernel amd64-es arch, vserver subarch verziójábal a 2.6.18-8 -as debian verziót látod, ami a 3-as series file-g van felpatchelve.
persze 7-es series file is van a kernel-patches csomagban, de az nem azt jelenti, hogy hivatalosan az etchben a mai napon a 3-asnál nagyobbat használnának; lásd még a saját uname -r kimenete: 2.6.18-3-vserver-amd64
további infok az új debian kernel mehanizmusáról a kernel-handbook -ban: http://kernel-handbook.alioth.debian.org/

hát 100%-ra nem állítottam, írtam is, hogy nem értek hozzá!
de ezt a bugreportot nézve azt láttam, hogy egyetlen egy ember tudta reprodukálni az is sid-et használ(ami unstable), 2.6.19-es NEM debian kernelt. és egy ember mondta eddig azt, hogy nem reprodukálható.
egyébként nálad is a -3 -as verzió van fent ;) de ezt egy picivel feljebb kifejtettem; ennek ellenére elhiszem, hogy tényleg van hibás szoftver :) és nyílván ezáltal hibás kernel a debianban ...

nem igazán vagyok tisztában ezzel a fájlrendszerkorrupciós buggal. tudom van cikk róla, de nem mélyedtem bele. (mondjuk mert nincs rtorrent pl.:))

A fedora-ból visszaportolt változtatások közvetlenül csak egyetlen ponton érintik a fs könyvtárat (ettől még persze a hiba lehet másol is, de a portolt változások többnyire memóriakezelést érintik), mégpedig a buffer.c-ben itt:

        spin_lock(&mapping->private_lock);
        ret = drop_buffers(page, &buffers_to_free);
+       spin_unlock(&mapping->private_lock);
        if (ret) {
                /*
                 * If the filesystem writes its buffers by hand (eg ext3)
                 * then we can have clean buffers against a dirty page.  We
                 * clean the page here; otherwise later reattachment of buffers
                 * could encounter a non-uptodate page, which is unresolvable.
                 * This only applies in the rare case where try_to_free_buffers
                 * succeeds but the page is not freed.
                 */
                clear_page_dirty(page);
        }
-       spin_unlock(&mapping->private_lock);

-------

Nem a zsömle kicsi, a pofátok nagy...