3 thoughts on “EULA Hotel

  1. That is the sketchiest place I know

    I temporarily lived right down the street at 16th and Van Ness when I first moved to SF. I was convinced that this was the sketchiest of the sketchy “hotels”. I always chuckle about the End User License Agreement that must be signed when you get a room. “Prostitution and drugs should be done behind closed doors if possible.”

    The bar next door, El Tin Tan, is also ridiculous. It seemingly is open 24 hours a day. I’ve definitely gone by at 8:00 in the morning and seen a few people at the bar drinking. Awesome…

    Now I’ve moved over off of Dolores Park. It’s amazing how much cleaner it is just a couple blocks west.

  2. Just some quick comments.

    NTFS supports POSIX symbolic links for at least for 7 years. I guess the
    3 years old presentation mentioned the native Vista symbolic links. The
    NTFS symlink, hardlink situation is confusing because there are several
    variants. We support all and create POSIX symbolic links by default.

    To be honest I can’t see parallel file system development worlds.
    Microsoft implemented basically all important things in 2000 what Unix
    file systems had. They had to, to be able to compete on the server field
    (scalability, full 64-bit, variable and large block size support, quota,
    symlink, hard link, special files, ACLs, auditing, inotify, content
    indexing, etc).

    The Unix world was also actively working on interoperability in the
    last 14 years. For instance just in the last two years we had over 235
    contributors. Understandably NTFS is out of the interest of most kernel
    file system developers but still many of Linux/Unix developers are
    working on it today.

    Feature wise ext4 is the closest tough NTFS is still significantly more
    bloated. Wiki, Microsoft NTFS related web pages and the latest open
    source NTFS layout.h file can give more details.

    In NTFS everything is file, including all metadata. The only fixed disk
    places are the 512 bytes size, redundant boot sectors: first and last
    sector of the partition. Where the metadata is placed is not NTFS
    specification but NTFS file system implementation specific. The
    block/cylinder/allocation groups are intentionally not hard-wired into
    the NTFS design but the driver implementation can choose the optimal
    strategy for the underlaying storage system.

    Sparse behavior is also implementation specific. Windows Win32 subsystem
    application must explicitly specify sparseness but Linux/Unix (NTFS-3G)
    applications don’t need to. NTFS-3G behaves exactly the same way as any
    other Linux/Unix file system. Otherwise it’s considered to be an
    implementation bug and we fix it.

    Who is allowed to create symlinks is also a driver implementation detail.
    Depending on several factors (mount options, driver type, etc) an NTFS-3G
    driver can allow it to anybody or only to those who have the permission
    to do so based on the Unix ownership/permission model mapped from Windows
    ACLs (Advanced NTFS-3G driver), or mount options (Stable NTFS-3G driver).

    Directory hard links are not permitted (that’s OSX/HPFS).

    I’m not sure online fsck is part of all Windows versions but I very much
    doubt it would be a hype. Today offline fsck is not competitive. NTFS-3G
    also has minimal online repair for some years. We do it not for marketing
    reasons but to significantly reduce user support requests and increase use
    satisfaction. This is again a driver implementation detail.

    The Files-11 origin (RSX-11, OpenVMS) of NTFS is indeed quite old and it
    predates NTFS introduction in 1993 by many years. Nevertheless the on-disk
    NTFS specification was designed to be 64-bit, flexible and extendable.

    The inefficient performance and fragmentation related comments are right
    however this is again a Microsoft NTFS driver implementation, not design
    issue. I don’t think anybody really knows what the NTFS design is capable
    of because nobody was close to a full-featured, optimized driver

    We have no plan for a pure NTFS kernel driver. We have found the hybrid
    kernel/user approach works better for this large project regards to rapid
    mass deployment, faster development cycles, higher reliability and
    performance, increased and easier portability, and reduced support


Comments are closed.

%d bloggers like this: