[News,Response] Linux Filesystems Put Microsoft Windows to Shame (andApple Macs) - Linux

This is a discussion on [News,Response] Linux Filesystems Put Microsoft Windows to Shame (andApple Macs) - Linux ; This may look a little weird but Google apparently can't see Roy's message yet. http://www.itwire.com/content/view/20943/1141/ makes several technical errors and omissions, to wit: [Omission] Because of a quirk in the original PC FDISK.EXE and/or DOS system, we now have the ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: [News,Response] Linux Filesystems Put Microsoft Windows to Shame (andApple Macs)

  1. [News,Response] Linux Filesystems Put Microsoft Windows to Shame (andApple Macs)

    This may look a little weird but Google apparently can't see Roy's
    message yet.

    http://www.itwire.com/content/view/20943/1141/

    makes several technical errors and omissions, to wit:

    [Omission] Because of a quirk in the original PC FDISK.EXE and/or DOS
    system, we now have the concept of primary, extended, and logical
    partitions. The article does not even mention the latter two, though
    it does walk the user through creation of one or two primary
    partitions (there can be maximum of four if one doesn't use an
    extended partition, or thee if one does) using Linux's fdisk (though
    without a transcript).

    [Major] df -k does not list connected drives, merely mounted ones.
    Both are, of course, useful. The -k is optional, but recommended

    [Major] Linux does not have *a* filesystem; it supports many
    filesystems, from ext2 to yaffs2 (a curio that was written by Google
    for some reason in their Android project, primarly intended for NAND
    flash units). Some of the filesystems are native to Linux, some
    borrowed or ported from other operating systems (e.g., FreeBSD and
    Windows).

    [Moderate] The tmpfs partition is not associated with a specific hard
    drive. It is a phantom filesystem, much like udev and proc; these
    allow for a (somewhat distorted) window into the bowels of the kernel,
    in a controlled fashion. In the case of tmpfs, the view is guaranteed
    to be initially empty, and grow as needs allow (and resources
    permit). The concept is similar to an old DOS-style ramdisk, although
    far more flexible in allocation. For their part udev gives a view
    into what devices Linux thinks are available, and proc is a catchall
    which includes process information (hence its name).

    [Minor] Linux does not use *a* dedicated disk partition for swap;
    Linux has many options, from one dedicated partition (type 0x82) to
    many such partitions, plus swap files. These can either be specified
    in /etc/fstab or added/removed on the fly, using swapon/swapoff.

    [Moderate] The automounting of hard drives is an option, and depends
    on how the kernel was built. In my case, I mount manually those
    drives not explicitly specified in /etc/fstab. To its credit, the
    article does mention /etc/fstab, though not in any real detail. I'd
    frankly have to study the issue but know a kernel automounter is
    specifiable as an option.

    [Moderate] One of the more interesting aspects of udev is that, if
    working properly (I might have a hardware issue with my 1 TB storage
    unit), the kernel will automagically detect and include in /dev/ the
    requisite nodes on a powered-up system when one shoves a cable into
    it. This is not a mount, but is required for mount to work; the
    actual mount might be handled by a supermount daemon, or possibly some
    other part of the kernel. Disconnecting a mounted drive will result
    in various interesting errors. (If one is fortunate enough to have an
    iomega or Syquest device, one will find that Linux locks the door if
    any partition is mounted on the inserted cartridge. Of course, USB
    and IEEE1394 have no such option, though if one has an IEEE1394-
    accessible iomega or Syquest, I suspect the door will still lock, even
    if one can pull the cable.)

    [Moderate] The article makes no mention at all of /dev/disk/by-*/*. /
    dev/disk/by-uuid in particular is a capability that allows for
    specifying a USB or IEEE1384 device without having to worry about
    exactly what order one plugs things in. Admittedly, this is probably
    too technical for an introductory article, but it's very powerful.

    [Minor] The article could have been clearer about the formatting
    process, though in all fairness most people think "formatting a
    partition". "Preparing a filesystem" would be more to my personal
    liking. All mkfs.ext2 et al do, after all, is scribble on the
    partition in such a manner that the kernel will later recognize it as
    a formatted filesystem. (In fact, the kernel doesn't even do the
    honors anymore; mount now punts to a specialized user-level program.
    Apparently this is a BSDism.)

    [Omission] The article does not comment at all about Windows' bad
    behavior upon encountering a foreign filesystem; it will happily allow
    the naive user to wipe data. To its credit, it at least asks first.
    (To be fair, Linux's mkfs.ext2 et al aren't much brighter, though they
    do check to see if the partition is mounted.)

    [Moderate] Not sure how "fabulous" the "/" filesystem is, versus
    Windows' single-letter or MacOS's labeled drive systems are. Granted,
    it's quite flexible, and the creation of /mount/david (all the way on
    the last page -- such a tease!) is an excellent example thereof. One
    of the comments, however, also mentions the LVM in Windows, introduced
    in the Win2k timeframe, if I'm not mistake; the capabilities are
    apparently almost identical. (One nice thing, of course: Unix was
    first here. I'm not that familiar with LVM, admittedly; not sure if
    my copy of XP has it, or not.)

    [Major] The "/" concept has very little to do with filesystems per se;
    it's mostly the preferred Unix method of organizing directories -- as
    opposed to, again, Windows' C:, D:, etc. or MacOS's now outdated
    methods.

    [Omission] Another technical subpoint, but one of the big, if
    generally invisible, advantages of Linux's filehandling capability --
    which is supported in various areas of the kernel -- is the concept of
    internal file nodes, or inodes for short. These allow for far more
    flexible filehandling (in particular, one can delete a file that's
    open, or rename over an open file). One drawback: the kernel gets a
    little more complicated in keeping track of inode operations, but
    that's OK. To see the numeric inode ID, one can do 'ls -i' in Linux;
    the resultant number is not all that useful (especially since it's
    specific to a filesystem; one can have two files with the same inode
    on different mounted partitions), though some programs do use .st_dev
    and .st_ino (provided by struct stat in the stat(2) system call) to
    see if two pathnames relate to the same object. There are locking
    issues as well, which I'll not go into here beyond mentioning that
    Linux locks are very short.

    [Omission] While minor, the article does not mention symbolic links
    and the differences between Windows' shortcuts and Linux's symlinks.
    (For starters, all programs can leverage Linux's symlinks; Windows'
    programs using shortcuts need to be careful, as they might end up
    reading the file -- helpfully suffixed .LNK -- instead, if they use
    CreateFile().)

    [Omission] NTFS has a btree; Linux's ext2 does not. I'd have to look
    regarding reiserfs and jfs. A btree, of course, conveniently allows
    the location of an object by name, by replacing a sequential scan of a
    directory with a log(N) scan of a datastructure (I don't know in
    NTFS's case whether it's global or per directory; I suspect the
    former). The drawback: a btree is a more complex structure to
    maintain.

    All in all, a nice piece of advocacy, if flawed in spots.

  2. Re: Linux Filesystems Put Microsoft Windows to Shame (and Apple Macs)

    Why don't you send your comments to the author?


  3. Re: Linux Filesystems Put Microsoft Windows to Shame (and Apple Macs)

    nessuno@wigner.berkeley.edu wrote:
    > Why don't you send your comments to the author?
    >



    Why don't you provide context by quoting the person you are replying to?

  4. Re: Linux Filesystems Put Microsoft Windows to Shame (and Apple Macs)

    Sean Keese espoused:
    > nessuno@wigner.berkeley.edu wrote:
    >> Why don't you send your comments to the author?
    >>

    >
    >
    > Why don't you provide context by quoting the person you are replying to?


    Are you Scott Douglas or Gary Stewart?

    Either way, you go in the killfile, anyway.

    --
    | mark at ellandroad dot demon dot co dot uk |
    | Cola faq: http://www.faqs.org/faqs/linux/advocacy/faq-and-primer/ |
    | Cola trolls: http://colatrolls.blogspot.com/ |
    | Open platforms prevent vendor lock-in. Own your Own services! |


  5. Re: Linux Filesystems Put Microsoft Windows to Shame (and Apple Macs)

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    ____/ Mark Kent on Thursday 02 October 2008 10:38 : \____

    > Sean Keese espoused:
    >> nessuno@wigner.berkeley.edu wrote:
    >>> Why don't you send your comments to the author?
    >>>

    >>
    >>
    >> Why don't you provide context by quoting the person you are replying to?

    >
    > Are you Scott Douglas or Gary Stewart?
    >
    > Either way, you go in the killfile, anyway.


    I think it's neither, but I killfiled it after the very first message that
    confirmed it's a returning (i.e. long-time) Microsoft Munchkin in a new gown
    (nym).

    - --
    ~~ Best of wishes

    Microsoft loves competition.
    "Linux is a cancer that attaches itself in an intellectual property sense to
    everything it touches."

    --Steve Ballmer, Microsoft CEO
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEARECAAYFAkjkur4ACgkQU4xAY3RXLo4O+wCfR9DSOr1xZO uNw2Dl2MJlo1hs
    MoEAnRKGnBdxWKDKqSGJW/ECQUJzIT8q
    =QG22
    -----END PGP SIGNATURE-----

  6. Re: Linux Filesystems Put Microsoft Windows to Shame (and Apple Macs)



    Hey, Sean! Have you seen Ezekiel lately? Funny how you showed up
    just about the time he disappeared! A new nym, fancy that, and one
    that seems to have long experience on cola! Well, that's the fate of
    sockpuppets, and it'll surely happen to you, too!!

    Also funny how flatfish's posting rate, which was way ahead of Roy for
    several months, has died down just as a thousand other nyms start
    popping up!! Now Tim can say with a straight face that Roy posts more
    than flatfish! That's the hardest part of his job, keeping a
    straight face!!

  7. Re: Linux Filesystems Put Microsoft Windows to Shame (and Apple Macs)

    nessuno@wigner.berkeley.edu espoused:
    >
    >
    > Hey, Sean! Have you seen Ezekiel lately? Funny how you showed up
    > just about the time he disappeared! A new nym, fancy that, and one
    > that seems to have long experience on cola! Well, that's the fate of
    > sockpuppets, and it'll surely happen to you, too!!
    >
    > Also funny how flatfish's posting rate, which was way ahead of Roy for
    > several months, has died down just as a thousand other nyms start
    > popping up!! Now Tim can say with a straight face that Roy posts more
    > than flatfish! That's the hardest part of his job, keeping a
    > straight face!!


    Quite... just the kind of thinking which was going through my mind,
    too...

    --
    | mark at ellandroad dot demon dot co dot uk |
    | Cola faq: http://www.faqs.org/faqs/linux/advocacy/faq-and-primer/ |
    | Cola trolls: http://colatrolls.blogspot.com/ |
    | Open platforms prevent vendor lock-in. Own your Own services! |


  8. Re: Linux Filesystems Put Microsoft Windows to Shame (and Apple Macs)

    Mark Kent wrote:
    > nessuno@wigner.berkeley.edu espoused:
    >>
    >>
    >> Hey, Sean! Have you seen Ezekiel lately? Funny how you showed up
    >> just about the time he disappeared! A new nym, fancy that, and one
    >> that seems to have long experience on cola! Well, that's the fate of
    >> sockpuppets, and it'll surely happen to you, too!!
    >>
    >> Also funny how flatfish's posting rate, which was way ahead of Roy
    >> for several months, has died down just as a thousand other nyms start
    >> popping up!! Now Tim can say with a straight face that Roy posts
    >> more than flatfish! That's the hardest part of his job, keeping a
    >> straight face!!

    >
    > Quite... just the kind of thinking which was going through my mind,
    > too...


    You mean the kind of ridiculous "thinking" that labels the Spamowitz moron
    "an esteemed author"?




  9. Re: Linux Filesystems Put Microsoft Windows to Shame (and Apple Macs)

    On Fri, 3 Oct 2008 10:27:05 -0400, DFS wrote:

    > Mark Kent wrote:
    >> nessuno@wigner.berkeley.edu espoused:
    >>>
    >>>
    >>> Hey, Sean! Have you seen Ezekiel lately? Funny how you showed up
    >>> just about the time he disappeared! A new nym, fancy that, and one
    >>> that seems to have long experience on cola! Well, that's the fate of
    >>> sockpuppets, and it'll surely happen to you, too!!
    >>>
    >>> Also funny how flatfish's posting rate, which was way ahead of Roy
    >>> for several months, has died down just as a thousand other nyms start
    >>> popping up!! Now Tim can say with a straight face that Roy posts
    >>> more than flatfish! That's the hardest part of his job, keeping a
    >>> straight face!!

    >>
    >> Quite... just the kind of thinking which was going through my mind,
    >> too...

    >
    > You mean the kind of ridiculous "thinking" that labels the Spamowitz moron
    > "an esteemed author"?


    Those idiots also miss the part where I plainly stated that my posting
    would be slowing down because my gig dumping 100's of vinyl to digital was
    ending and my next gig involved more field work.

    Of course they have to take every opportunity to twist things because they
    are empty suits with nothing much to say.

    Roy an "esteemed" author?
    Ha!
    That's a good one.

    What magazine?

    "Paranoia Weekly" ?

    Roy's a jerk who can't make it in real life so he hides in University level
    research.
    --
    Moshe Goldfarb
    Collector of soaps from around the globe.
    Please visit The Hall of Linux Idiots:
    http://linuxidiots.blogspot.com/
    Please Visit www.linsux.org

+ Reply to Thread