Re: Why There's a "Dim" in Dimdows - Microsoft Windows

This is a discussion on Re: Why There's a "Dim" in Dimdows - Microsoft Windows ; Here's another interesting item , listing some of the innovative features in Linux, particularly compared to the aging Windows architecture. Things like: * it being trivially easy to determine exactly which configuration options were used to build the running kernel, ...

+ Reply to Thread
Results 1 to 16 of 16

Thread: Re: Why There's a "Dim" in Dimdows

  1. Re: Why There's a "Dim" in Dimdows

    Here's another interesting item
    , listing some of the
    innovative features in Linux, particularly compared to the aging Windows
    architecture. Things like:

    * it being trivially easy to determine exactly which configuration options
    were used to build the running kernel, and copy those exact same options
    for building your own (so you can tweak exactly the settings you want, and
    leave the rest the same).
    * dynamically loadable modules allowing you to change your driver setup with
    a minimum of rebooting.
    * EFI support. Even Dimdows Vista will be lagging behind here.
    * built-in software RAID with logical volume management.
    * journalled filesystem support.
    * much superior support for hot-pluggable storage devices.

    The last point has to do with the archaic drive-letter scheme you're forced
    to use in Dimdows, compared to the much more flexible mount-point system in
    Linux. The latter lets you give meaningful names to your volumes, and also
    set up udev rules, based on the unique serial numbers of your devices, so
    every time you plug them in, they reappear in the same place. Compare this
    with Dimdows, where first of all you have a limit of 26 drive letters, and
    secondly you have no control over which ones are assigned to your
    hot-pluggable devices, so you have no idea which drive letter refers to
    which device.

  2. Re: Why There's a "Dim" in Dimdows

    On Sat, 15 Apr 2006 13:54:11 +1200, Lawrence D'Oliveiro wrote:

    > Here's another interesting item
    > , listing some of the
    > innovative features in Linux, particularly compared to the aging Windows
    > architecture. Things like:


    And, like most Linux users, is almost completely wrong about everything.

    > * it being trivially easy to determine exactly which configuration options
    > were used to build the running kernel, and copy those exact same options
    > for building your own (so you can tweak exactly the settings you want, and
    > leave the rest the same).


    What it doesn't tell you is a) what other patches may have been installed,
    unless those patches provide kernel config options. b) what version of
    those kernel patches may have been applied, and c) what modules may be
    included that arent' standard. All of which is required knowledge to
    rebuild an identical kernel.

    > * dynamically loadable modules allowing you to change your driver setup with
    > a minimum of rebooting.


    Of course pretty much every OS has dynamically loaded drivers. Windows
    does. MacOS does. Linux does. Nothing innovative here. About the only
    driver that really requires a reboot is video drivers, though some hardware
    installs supplementary files that often ask for a reboot.

    > * EFI support. Even Dimdows Vista will be lagging behind here.


    EFI support is there in 64 bit Windows.

    > * built-in software RAID with logical volume management.


    Windows has had this for many years.

    > * journalled filesystem support.


    Again, many years (since 1993 in fact).

    > * much superior support for hot-pluggable storage devices.


    hardly. Oh, i'm sure you'll dredge up the old tired "out of the box"
    argument.

    > The last point has to do with the archaic drive-letter scheme you're forced
    > to use in Dimdows, compared to the much more flexible mount-point system in
    > Linux.


    As usualy, wrong. NTFS supports volume mountpoints as well. You can mount
    any volume in a directory of your hard drive, just like Linux. Not
    requiring a drive letter for anything other than the root drive.

    > The latter lets you give meaningful names to your volumes, and also
    > set up udev rules, based on the unique serial numbers of your devices, so
    > every time you plug them in, they reappear in the same place. Compare this
    > with Dimdows, where first of all you have a limit of 26 drive letters, and
    > secondly you have no control over which ones are assigned to your
    > hot-pluggable devices, so you have no idea which drive letter refers to
    > which device.


    Wrong again. You can define exactly what drive letters are assigned to any
    drive, including hot pluggable ones. So, if you want to mount them in a
    folder, you can. If you want to use a drive letter, you can, and define
    where it is. As usual, you simply don't know what you are talking about.

  3. Re: Why There's a "Dim" in Dimdows

    In article ,
    Lawrence D'Oliveiro wrote:
    > Here's another interesting item
    > , listing some of the
    > innovative features in Linux, particularly compared to the aging Windows
    > architecture. Things like:

    ....
    > * dynamically loadable modules allowing you to change your driver setup with
    > a minimum of rebooting.


    We had that in 386/ix at Interactive Systems Corp in 1987 or 1988. I'm
    not sure if that was the first Unix to have this or not.

    ....
    > * journalled filesystem support.


    Several years after NT had it.

    > * much superior support for hot-pluggable storage devices.
    >
    > The last point has to do with the archaic drive-letter scheme you're forced
    > to use in Dimdows, compared to the much more flexible mount-point system in
    > Linux. The latter lets you give meaningful names to your volumes, and also


    Yeah, finding my USB thumb drive show up as

    /media/usb-storage-F858D0B77DE2FF5F:0:0:0p1

    is much better than having it show up as E:\.


    --
    --Tim Smith

  4. Re: Why There's a "Dim" in Dimdows

    In article <1n26k8s6vf4nh.dlg@funkenbusch.com>,
    Erik Funkenbusch wrote:

    >On Sat, 15 Apr 2006 13:54:11 +1200, Lawrence D'Oliveiro wrote:
    >
    >> Here's another interesting item
    >> , listing some of the
    >> innovative features in Linux, particularly compared to the aging Windows
    >> architecture. Things like:

    >
    >And, like most Linux users, is almost completely wrong about everything.
    >
    >> * it being trivially easy to determine exactly which configuration options
    >> were used to build the running kernel, and copy those exact same options
    >> for building your own (so you can tweak exactly the settings you want, and
    >> leave the rest the same).

    >
    >What it doesn't tell you is a) what other patches may have been installed,
    >unless those patches provide kernel config options. b) what version of
    >those kernel patches may have been applied, and c) what modules may be
    >included that arent' standard. All of which is required knowledge to
    >rebuild an identical kernel.


    And Dimdows is better in this regard how?

    >> * dynamically loadable modules allowing you to change your driver setup with
    >> a minimum of rebooting.

    >
    >Of course pretty much every OS has dynamically loaded drivers. Windows
    >does.


    Then why does Windows require a reboot every time you install/update
    your drivers?

    >> * EFI support. Even Dimdows Vista will be lagging behind here.

    >
    >EFI support is there in 64 bit Windows.


    And 64-bit Windows is lagging in driver support.

    >> The last point has to do with the archaic drive-letter scheme you're forced
    >> to use in Dimdows, compared to the much more flexible mount-point system in
    >> Linux.

    >
    >As usualy, wrong. NTFS supports volume mountpoints as well. You can mount
    >any volume in a directory of your hard drive, just like Linux. Not
    >requiring a drive letter for anything other than the root drive.


    Here you go again, claiming something in theory that no Dimdows user is
    actually able to achieve in practice.

    >> The latter lets you give meaningful names to your volumes, and also
    >> set up udev rules, based on the unique serial numbers of your devices, so
    >> every time you plug them in, they reappear in the same place. Compare this
    >> with Dimdows, where first of all you have a limit of 26 drive letters, and
    >> secondly you have no control over which ones are assigned to your
    >> hot-pluggable devices, so you have no idea which drive letter refers to
    >> which device.

    >
    >Wrong again. You can define exactly what drive letters are assigned to any
    >drive, including hot pluggable ones.


    And yet no ordinary Dimdows user, it seems, is able to do this.

  5. Re: Why There's a "Dim" in Dimdows

    Erik Funkenbusch wrote:

    > On Sat, 15 Apr 2006 13:54:11 +1200, Lawrence D'Oliveiro wrote:
    >
    >> Here's another interesting item
    >> , listing some of the
    >> innovative features in Linux, particularly compared to the aging Windows
    >> architecture. Things like:

    >
    > And, like most Linux users, is almost completely wrong about everything.
    >
    >> * it being trivially easy to determine exactly which configuration
    >> options were used to build the running kernel, and copy those exact same
    >> options for building your own (so you can tweak exactly the settings you
    >> want, and leave the rest the same).

    >
    > What it doesn't tell you is a) what other patches may have been installed,
    > unless those patches provide kernel config options.


    Huh? What are you blubbering about? And why do you always have to construe a
    situation with some, undefined naturally, "patches" which /may/ have been
    applied? You are aware that the source for those *exact* patches is also
    present? Why not? Do you always have to work on being an extremely stupid
    and dishonest windows-user, Erik?

    > b) what version of those kernel patches may have been applied,


    Irrelevant. The exact same version as the "patched" ones are there in the
    sources

    > and c) what modules may be included that arent' standard.


    Again, included in the sources. Have you *ever* build a kernel, Erik?

    > All of which is required knowledge to rebuild an identical kernel.
    >


    You are full of it, as usual, Erik
    What part of "make cloneconfig" to get the *exact* config of the running
    kernel needs some more explanation for you?

    < snip >
    --
    If you had any brains, you'd be dangerous.


  6. Re: Why There's a "Dim" in Dimdows

    On Sat, 15 Apr 2006 19:19:49 +1200, Lawrence D'Oliveiro wrote:

    >>> * it being trivially easy to determine exactly which configuration options
    >>> were used to build the running kernel, and copy those exact same options
    >>> for building your own (so you can tweak exactly the settings you want, and
    >>> leave the rest the same).

    >>
    >>What it doesn't tell you is a) what other patches may have been installed,
    >>unless those patches provide kernel config options. b) what version of
    >>those kernel patches may have been applied, and c) what modules may be
    >>included that arent' standard. All of which is required knowledge to
    >>rebuild an identical kernel.

    >
    > And Dimdows is better in this regard how?


    I don't have to prove that Windows is better, only that your argument is
    flawed. You argued taht you could recreate your kernel knowing only the
    previous config used, I pointed out how you are wrong, you need a lot more.

    >>> * dynamically loadable modules allowing you to change your driver setup with
    >>> a minimum of rebooting.

    >>
    >>Of course pretty much every OS has dynamically loaded drivers. Windows
    >>does.

    >
    > Then why does Windows require a reboot every time you install/update
    > your drivers?


    It doesn't. I load an unload drivers all the time. For example, when you
    plug in a USB drive, and the balloon pops up saying the device is now ready
    for use. It just loaded a driver.

    >>> * EFI support. Even Dimdows Vista will be lagging behind here.

    >>
    >>EFI support is there in 64 bit Windows.

    >
    > And 64-bit Windows is lagging in driver support.


    Nice argument switch.

    >>> The last point has to do with the archaic drive-letter scheme you're forced
    >>> to use in Dimdows, compared to the much more flexible mount-point system in
    >>> Linux.

    >>
    >>As usualy, wrong. NTFS supports volume mountpoints as well. You can mount
    >>any volume in a directory of your hard drive, just like Linux. Not
    >>requiring a drive letter for anything other than the root drive.

    >
    > Here you go again, claiming something in theory that no Dimdows user is
    > actually able to achieve in practice.


    Bull****. Lots of people do it, including myself. Just because YOU don't
    know how doesn't mean nobody is using it. The point, of course, is that
    you are wrong, as usual. Why don't you just stop talking about what you
    think you know about windows, since you are always wrong when you do?

    >>> The latter lets you give meaningful names to your volumes, and also
    >>> set up udev rules, based on the unique serial numbers of your devices, so
    >>> every time you plug them in, they reappear in the same place. Compare this
    >>> with Dimdows, where first of all you have a limit of 26 drive letters, and
    >>> secondly you have no control over which ones are assigned to your
    >>> hot-pluggable devices, so you have no idea which drive letter refers to
    >>> which device.

    >>
    >>Wrong again. You can define exactly what drive letters are assigned to any
    >>drive, including hot pluggable ones.

    >
    > And yet no ordinary Dimdows user, it seems, is able to do this.


    It's bone simple. Right Click My computer, choose manage, choose disk
    management, right click on a partition and choose Change Drive Letter and
    Paths.

  7. Re: Why There's a "Dim" in Dimdows

    In article
    ,
    Tim Smith wrote:

    >Yeah, finding my USB thumb drive show up as
    >
    > /media/usb-storage-F858D0B77DE2FF5F:0:0:0p1
    >
    >is much better than having it show up as E:\.


    That is *so* true! And don't you think the foward-slash is a sign of a
    forward-looking platform, unlike the backward-slash that Dimdows uses?

  8. Re: Why There's a "Dim" in Dimdows

    On Sun, 16 Apr 2006 14:55:58 +1200, Lawrence D'Oliveiro wrote:

    > In article
    > ,
    > Tim Smith wrote:
    >
    >>Yeah, finding my USB thumb drive show up as
    >>
    >> /media/usb-storage-F858D0B77DE2FF5F:0:0:0p1
    >>
    >>is much better than having it show up as E:\.

    >
    > That is *so* true! And don't you think the foward-slash is a sign of a
    > forward-looking platform, unlike the backward-slash that Dimdows uses?


    Your sarcasm detector is broken. Oh, wait. You're just an idiot.

  9. Re: Why There's a "Dim" in Dimdows

    In article
    ,
    Tim Smith wrote:

    >In article ,
    > Lawrence D'Oliveiro wrote:
    >
    >> * much superior support for hot-pluggable storage devices.
    >>
    >> The last point has to do with the archaic drive-letter scheme you're forced
    >> to use in Dimdows, compared to the much more flexible mount-point system in
    >> Linux. The latter lets you give meaningful names to your volumes, and also

    >
    >Yeah, finding my USB thumb drive show up as
    >
    > /media/usb-storage-F858D0B77DE2FF5F:0:0:0p1
    >
    >is much better than having it show up as E:\.


    Much better. Instead of having it sometimes pop up as E:, and sometimes
    as F:, and sometimes as G:.

  10. Re: Why There's a "Dim" in Dimdows

    In article <1xuo1hwgg25yg$.dlg@funkenbusch.com>,
    Erik Funkenbusch wrote:

    >Let's say you've got a copy of SUSE 9.1, and you want to
    >download the latest stable kernel from from kernel.org, but you need to
    >apply all the patches that Novell has applied to their stock kernel.
    >
    >Now, how do you get ahold of those patches?


    Download and install the SuSE-provided source RPM. Apply the patches to
    the appropriate standard kernel sources using the patch(1) tool, which
    is the same method the SuSE folks themselves use. Typically, the patches
    are broken out into separate files, so you can choose to apply just some
    of them, rather than all of them. Or indeed, not bother to apply any of
    them at all.

  11. Re: Why There's a "Dim" in Dimdows

    In article <3cx0fcf3syaw.dlg@funkenbusch.com>,
    Erik Funkenbusch wrote:

    >On Sat, 15 Apr 2006 19:19:49 +1200, Lawrence D'Oliveiro wrote:
    >
    >>>> * it being trivially easy to determine exactly which configuration options
    >>>> were used to build the running kernel, and copy those exact same options
    >>>> for building your own (so you can tweak exactly the settings you want, and
    >>>> leave the rest the same).
    >>>
    >>>What it doesn't tell you is a) what other patches may have been installed,
    >>>unless those patches provide kernel config options. b) what version of
    >>>those kernel patches may have been applied, and c) what modules may be
    >>>included that arent' standard. All of which is required knowledge to
    >>>rebuild an identical kernel.

    >>
    >> And Dimdows is better in this regard how?

    >
    >I don't have to prove that Windows is better, only that your argument is
    >flawed. You argued taht you could recreate your kernel knowing only the
    >previous config used, I pointed out how you are wrong, you need a lot more.


    Kernel configuration is a separate issue from kernel patching. The Linux
    kernel allows you to configure it in all kinds of ways without actually
    having to resort to code patches. Bringing in the issue of code patches
    is a red herring.

    >>>> * dynamically loadable modules allowing you to change your driver setup
    >>>> with
    >>>> a minimum of rebooting.
    >>>
    >>>Of course pretty much every OS has dynamically loaded drivers. Windows
    >>>does.

    >>
    >> Then why does Windows require a reboot every time you install/update
    >> your drivers?

    >
    >It doesn't. I load an unload drivers all the time. For example, when you
    >plug in a USB drive, and the balloon pops up saying the device is now ready
    >for use. It just loaded a driver.


    The standard Dimdows installation technique for a new device says to
    only do that _after_ you have installed the software for your new USB
    device (and done at least one reboot in the process).

    >>>> * EFI support. Even Dimdows Vista will be lagging behind here.
    >>>
    >>>EFI support is there in 64 bit Windows.

    >>
    >> And 64-bit Windows is lagging in driver support.

    >
    >Nice argument switch.


    You were the one who brought up 64-bit Windows. Which is kind of stuck
    in a chicken-and-egg situation, isn't it? People are reluctant to switch
    to 64-bit Dimdows until there is better driver/hardware support for it,
    but the hardware vendors are reluctant to spend twice as much effort on
    testing, debugging QA, support and so on to develop two drivers (32-bit
    and 64-bit), when there is so little demand from customers.

    Contrast this with Linux, which has been available in full 64-bit
    versions, with full 64-bit drivers and full 64-bit applications, for
    years.

    >>>> The last point has to do with the archaic drive-letter scheme you're
    >>>> forced
    >>>> to use in Dimdows, compared to the much more flexible mount-point system
    >>>> in
    >>>> Linux.
    >>>
    >>>As usualy, wrong. NTFS supports volume mountpoints as well. You can mount
    >>>any volume in a directory of your hard drive, just like Linux. Not
    >>>requiring a drive letter for anything other than the root drive.

    >>
    >> Here you go again, claiming something in theory that no Dimdows user is
    >> actually able to achieve in practice.

    >
    >Bull****. Lots of people do it, including myself.


    Hands up all those who think Mr F here is right, and have done this sort
    of thing for themselves no problem.

    .... anybody ...?

    .... thought not.

    >>>> The latter lets you give meaningful names to your volumes, and also
    >>>> set up udev rules, based on the unique serial numbers of your devices, so
    >>>> every time you plug them in, they reappear in the same place. Compare this
    >>>> with Dimdows, where first of all you have a limit of 26 drive letters, and
    >>>> secondly you have no control over which ones are assigned to your
    >>>> hot-pluggable devices, so you have no idea which drive letter refers to
    >>>> which device.
    >>>
    >>>Wrong again. You can define exactly what drive letters are assigned to any
    >>>drive, including hot pluggable ones.

    >>
    >> And yet no ordinary Dimdows user, it seems, is able to do this.

    >
    >It's bone simple. Right Click My computer, choose manage, choose disk
    >management, right click on a partition and choose Change Drive Letter and
    >Paths.


    So simple in theory. And yet no ordinary Dimdows user, it seems, is able
    to figure this out. Wonder why that is?

  12. Re: Why There's a "Dim" in Dimdows

    On Sun, 16 Apr 2006 15:09:31 +1200, Lawrence D'Oliveiro wrote:

    >>I don't have to prove that Windows is better, only that your argument is
    >>flawed. You argued taht you could recreate your kernel knowing only the
    >>previous config used, I pointed out how you are wrong, you need a lot more.

    >
    > Kernel configuration is a separate issue from kernel patching. The Linux
    > kernel allows you to configure it in all kinds of ways without actually
    > having to resort to code patches. Bringing in the issue of code patches
    > is a red herring.


    No, it's not. You were saying that when you build a new kernel, you need
    only get the kernel config from proc. That's wrong, there are other things
    you have to do.

    >>> Then why does Windows require a reboot every time you install/update
    >>> your drivers?

    >>
    >>It doesn't. I load an unload drivers all the time. For example, when you
    >>plug in a USB drive, and the balloon pops up saying the device is now ready
    >>for use. It just loaded a driver.

    >
    > The standard Dimdows installation technique for a new device says to
    > only do that _after_ you have installed the software for your new USB
    > device (and done at least one reboot in the process).


    You are confusing driver installation, and driver loading and unloading.
    They're two different things. Most drivers can be loaded and unloaded
    dynamically.

    Some drivers cannot be installed without a reboot, but that's largely the
    fault of the driver developers. Their installation routine could deal with
    all the issues, but forcing a reboot is the lazy way.

    And none of that "must install software before connecting your device" is
    necessary either. This is just the driver vendors adapting to the fact
    that when a user connects a device that doesn't have a driver, then follows
    the wizard without installing a driver, the device becomes "unknown" and
    installing the drive afterwards will not automatically re-detect it.

    If you know what you're doing, you just go into device manager delete the
    unknown device, then rescan for new hardware. Most of the time this does
    not require a reboot at all. It's just lazy driver vendors that force you
    to.

    >>>>> * EFI support. Even Dimdows Vista will be lagging behind here.
    >>>>
    >>>>EFI support is there in 64 bit Windows.
    >>>
    >>> And 64-bit Windows is lagging in driver support.

    >>
    >>Nice argument switch.

    >
    > You were the one who brought up 64-bit Windows. Which is kind of stuck
    > in a chicken-and-egg situation, isn't it? People are reluctant to switch
    > to 64-bit Dimdows until there is better driver/hardware support for it,
    > but the hardware vendors are reluctant to spend twice as much effort on
    > testing, debugging QA, support and so on to develop two drivers (32-bit
    > and 64-bit), when there is so little demand from customers.


    Most vendors are writing 64 bit drivers for their new hardware hardware.
    Every piece of hardware I own has 64 bit drivers, and I didn't plan it that
    way. nVidia has 64 bit video and nForce 4 chipset drivers. Silicon Image
    has 64 bit SATA drivers.

    > Contrast this with Linux, which has been available in full 64-bit
    > versions, with full 64-bit drivers and full 64-bit applications, for
    > years.


    So what? I can run 64 bit Windows today, but I don't, because I have no
    need for it.

    >>Bull****. Lots of people do it, including myself.

    >
    > Hands up all those who think Mr F here is right, and have done this sort
    > of thing for themselves no problem.
    >
    > ... anybody ...?
    >
    > ... thought not.


    You're in a Linux forum, moron.

    >>> And yet no ordinary Dimdows user, it seems, is able to do this.

    >>
    >>It's bone simple. Right Click My computer, choose manage, choose disk
    >>management, right click on a partition and choose Change Drive Letter and
    >>Paths.

    >
    > So simple in theory. And yet no ordinary Dimdows user, it seems, is able
    > to figure this out. Wonder why that is?


    Because you live in a fantasy world where you believe that just because YOU
    don't know about something, or don't use something, nobody else does
    either.

  13. Re: Why There's a "Dim" in Dimdows

    After takin' a swig o' grog, Erik Funkenbusch belched out this bit o' wisdom:

    > On Sun, 16 Apr 2006 14:55:58 +1200, Lawrence D'Oliveiro wrote:
    >
    >>>Yeah, finding my USB thumb drive show up as
    >>>
    >>> /media/usb-storage-F858D0B77DE2FF5F:0:0:0p1
    >>>
    >>>is much better than having it show up as E:\.

    >>
    >> That is *so* true! And don't you think the foward-slash is a sign of a
    >> forward-looking platform, unlike the backward-slash that Dimdows uses?

    >
    > Your sarcasm detector is broken. Oh, wait. You're just an idiot.


    Uh, Erik, can you say again just whose sarcasm detector is broken, laddie?

    --
    Kreegah! Bundolo Microsoft bolgani!

  14. Re: Why There's a "Dim" in Dimdows

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

    On 2006-04-16, Erik Funkenbusch spake thusly:
    > On Sun, 16 Apr 2006 14:55:58 +1200, Lawrence D'Oliveiro wrote:
    >
    >> In article
    >> ,
    >> Tim Smith wrote:
    >>
    >>>Yeah, finding my USB thumb drive show up as
    >>>
    >>> /media/usb-storage-F858D0B77DE2FF5F:0:0:0p1
    >>>
    >>>is much better than having it show up as E:\.

    >>
    >> That is *so* true! And don't you think the foward-slash is a sign of a
    >> forward-looking platform, unlike the backward-slash that Dimdows uses?

    >
    > Your sarcasm detector is broken. Oh, wait. You're just an idiot.


    Eric, such language (finger waving back and forth). Tsk, Tsk, I wonder;
    do you reserve this for windows groups or are you getting ready to
    reveal this side of your personality in C.O.L.A.?

    Inquiring minds want to know .....



    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.7 (GNU/Linux)

    iD8DBQFEWS4mlkJ5K/IU2ToRAtNsAJsHnYE+BU8c073lg95hZ8ZHLa+xHwCgyJKb
    tTuk4S+YzT1T0zlZtC5VRZQ=
    =CXHn
    -----END PGP SIGNATURE-----

  15. Re: Why There's a "Dim" in Dimdows

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

    On 2006-04-15, Erik Funkenbusch spake thusly:
    > On Sat, 15 Apr 2006 19:19:49 +1200, Lawrence D'Oliveiro wrote:
    >
    >>>> * it being trivially easy to determine exactly which configuration options
    >>>> were used to build the running kernel, and copy those exact same options
    >>>> for building your own (so you can tweak exactly the settings you want, and
    >>>> leave the rest the same).
    >>>
    >>>What it doesn't tell you is a) what other patches may have been installed,
    >>>unless those patches provide kernel config options. b) what version of
    >>>those kernel patches may have been applied, and c) what modules may be
    >>>included that arent' standard. All of which is required knowledge to
    >>>rebuild an identical kernel.

    >>
    >> And Dimdows is better in this regard how?

    >
    > I don't have to prove that Windows is better, only that your argument is
    > flawed. You argued taht you could recreate your kernel knowing only the
    > previous config used, I pointed out how you are wrong, you need a lot more.


    Strawman Eric. Thats what I'm going to call you.

    >>>> * dynamically loadable modules allowing you to change your driver setup with
    >>>> a minimum of rebooting.
    >>>
    >>>Of course pretty much every OS has dynamically loaded drivers. Windows
    >>>does.

    >>
    >> Then why does Windows require a reboot every time you install/update
    >> your drivers?

    >
    > It doesn't. I load an unload drivers all the time. For example, when you
    > plug in a USB drive, and the balloon pops up saying the device is now ready
    > for use. It just loaded a driver.


    He wasn't talking about auto-mounting, which windows does every time it
    does a so called "hot plug". When you plug in the usb drive, windows
    mounts it. Of course, that isn't what it's called in the windows world
    but it's the same process. Mounting a device doesen't load/install a driver.
    Any more than it does in Linux. That's why windows hardware usually comes
    with an install disk. It is neccesary to initially install the needed
    drivers into the system before the device can be used; hotplug, or no
    hot plug. When this is done, *you do have to perform a soft restart* . If
    no install disk is needed, it's because the drivers were already there.

    >>>> * EFI support. Even Dimdows Vista will be lagging behind here.
    >>>
    >>>EFI support is there in 64 bit Windows.

    >>
    >> And 64-bit Windows is lagging in driver support.

    >
    > Nice argument switch.
    >
    >>>> The last point has to do with the archaic drive-letter scheme you're forced
    >>>> to use in Dimdows, compared to the much more flexible mount-point system in
    >>>> Linux.


    The mount point system that *nix is based around can be *very* confusing to a
    newcomer, especially someone who is trying to make the transition from a
    totally foreign (using *nix as a reference point) OS. If I had to guess, I
    would say that this concept is the _one_ most difficult to grasp elements of
    Linux, BSD, what have you, that there is, and I would hazard to say it
    turns off many potential users.

    It may be more flexible than differentiating hardware from software by name and
    OS handling, but when this is what you are used to, it's hard to learn to think
    in new terms.

    The major difference between *nix and other OS's, namely windows, is that
    in *nix, *everything* is a file. This is a very hard concept for newbies to
    *nix, being used to the OS differentiating hardware and software by named
    designation. The idea that every part of the computer - hardware, or software,
    is a file to the OS, and that the OS dosen't care whether a device is
    physical or exists only as data, is really a mind bender for the newcomer.
    The fact that it actually works more efficiently is, at this point in the
    new users experience, irrelevant.

    So the point becomes; if the drive letter system is archaic, even inneficient,
    that's OK, especially if it helps a newcomer to make a smooth transition from
    windows to *nix.

    >>>As usualy, wrong. NTFS supports volume mountpoints as well. You can mount
    >>>any volume in a directory of your hard drive, just like Linux. Not
    >>>requiring a drive letter for anything other than the root drive.


    NTFS is quite possibly the worst file system ever concieved of by the mind of
    man. Even MS had to fess up to that one.

    >> Here you go again, claiming something in theory that no Dimdows user is
    >> actually able to achieve in practice.

    >
    > Bull****. Lots of people do it, including myself. Just because YOU don't
    > know how doesn't mean nobody is using it. The point, of course, is that
    > you are wrong, as usual. Why don't you just stop talking about what you
    > think you know about windows, since you are always wrong when you do?
    >
    >>>> The latter lets you give meaningful names to your volumes, and also
    >>>> set up udev rules, based on the unique serial numbers of your devices, so
    >>>> every time you plug them in, they reappear in the same place. Compare this
    >>>> with Dimdows, where first of all you have a limit of 26 drive letters, and
    >>>> secondly you have no control over which ones are assigned to your
    >>>> hot-pluggable devices, so you have no idea which drive letter refers to
    >>>> which device.


    Windows has a default order of assignment that can be, but usually isn't, changed
    by the user. Unless a hardware change is made, the designation remains the same.
    By the way, You may want to drop "dimdows". It's goofy.

    >>>Wrong again. You can define exactly what drive letters are assigned to any
    >>>drive, including hot pluggable ones.

    >>
    >> And yet no ordinary Dimdows user, it seems, is able to do this.

    >
    > It's bone simple. Right Click My computer, choose manage, choose disk
    > management, right click on a partition and choose Change Drive Letter and
    > Paths.


    Haven't used windows for a long time, but if it's that simple they have
    *vastly* improved the interface since '98. I am talking a major
    improvement here.

    regards,

    Mathew


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.7 (GNU/Linux)

    iD8DBQFEWXd+lkJ5K/IU2ToRAoEpAJ44//0VLHA4yvJyNtPJAGzphDAbGACgvHdN
    wH6tvWEYOk49cktGg3aviKw=
    =nAM3
    -----END PGP SIGNATURE-----

  16. Re: Why There's a "Dim" in Dimdows

    Tim Smith wrote:

    > In article ,
    > Lawrence D'Oliveiro wrote:
    >> Here's another interesting item
    >> , listing some of the
    >> innovative features in Linux, particularly compared to the aging Windows
    >> architecture. Things like:

    > ...
    >> * dynamically loadable modules allowing you to change your driver setup
    >> with a minimum of rebooting.

    >
    > We had that in 386/ix at Interactive Systems Corp in 1987 or 1988. I'm
    > not sure if that was the first Unix to have this or not.
    >
    > ...
    >> * journalled filesystem support.

    >
    > Several years after NT had it.
    >
    >> * much superior support for hot-pluggable storage devices.
    >>
    >> The last point has to do with the archaic drive-letter scheme you're
    >> forced to use in Dimdows, compared to the much more flexible mount-point
    >> system in Linux. The latter lets you give meaningful names to your
    >> volumes, and also

    >
    > Yeah, finding my USB thumb drive show up as
    >
    > /media/usb-storage-F858D0B77DE2FF5F:0:0:0p1
    >
    > is much better than having it show up as E:\.
    >
    >


    The name you gave is created on the fly when the device is put in, because
    it is a transient device and the OS doesn't know what you want it to be
    called, you only need to see it once then you can have that one default to
    a better name of your choosing.

    So now each device you plug in announces itself.

    ex,
    /media/usb-MyMP3-player
    /media/usb-MyPDA
    /media/ieee-MyCamCorder

    Or change some so that they mount in a handier place where you are more
    likely to use it.

    /home/username/mymusic
    /home/username/mymusic/usb-MyMP3-player




+ Reply to Thread