Universal Package Manager System for Linux? - Linux

This is a discussion on Universal Package Manager System for Linux? - Linux ; On 1 heinš, 22:26, Bernd Strieder wrote: > Hello, > > tsaar2...@yahoo.com wrote: > > As I see it, if Linux wants to be a major desktop operating system, it > > needs a simple AND unified on-click package management ...

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 41 to 60 of 63

Thread: Universal Package Manager System for Linux?

  1. Re: Universal Package Manager System for Linux?

    On 1 heinš, 22:26, Bernd Strieder
    wrote:
    > Hello,
    >
    > tsaar2...@yahoo.com wrote:
    > > As I see it, if Linux wants to be a major desktop operating system, it
    > > needs a simple AND unified on-click package management system, which
    > > is so simple that even my 80 year old grandmother is able to install
    > > applications and needed drivers on her system.

    >
    > There is no package system out there which is perfect, no commercial
    > systems and none of the opensource systems, all have had misconceptions
    > and errors from time to time. They are all work in progress. Most of
    > their differences originate in different goals of those writing the
    > management, of those packing the packages, of those using and
    > installing the packages. The biggest hindrance towards unification is
    > that most are satisfied with their current solution, and doing it even
    > better than to satisfaction is not possible. Your real task is to unify
    > developers, users and packagers in a way that they give up the specific
    > advantages of their current solution for the unification, and that will
    > not work as history tells. At its best it degrades into just another
    > package manager with its share of followers.
    >
    > Bernd Strieder


    I would see this as a great opportunity, as there are - and there has
    been - a number of different package managers with different success
    rates. Maybe we could learn from their misconceptions and errors, and
    take the best parts of each manager to create a unified and universal
    package manager ie. to create something which will provide the
    greatest common dominator of the successful package managers.

    When I say, "unified and universal", I mean that the basic operations
    and "user experience" need to be similar to the ordinary desktop user.
    For the expert users, the different distros may provide some
    additional features that are needed for this specific distro.

    /TS

  2. Re: Universal Package Manager System for Linux?

    On 1 heinš, 22:26, Bernd Strieder
    wrote:
    > Hello,
    >
    > tsaar2...@yahoo.com wrote:
    > > As I see it, if Linux wants to be a major desktop operating system, it
    > > needs a simple AND unified on-click package management system, which
    > > is so simple that even my 80 year old grandmother is able to install
    > > applications and needed drivers on her system.

    >
    > There is no package system out there which is perfect, no commercial
    > systems and none of the opensource systems, all have had misconceptions
    > and errors from time to time. They are all work in progress. Most of
    > their differences originate in different goals of those writing the
    > management, of those packing the packages, of those using and
    > installing the packages. The biggest hindrance towards unification is
    > that most are satisfied with their current solution, and doing it even
    > better than to satisfaction is not possible. Your real task is to unify
    > developers, users and packagers in a way that they give up the specific
    > advantages of their current solution for the unification, and that will
    > not work as history tells. At its best it degrades into just another
    > package manager with its share of followers.
    >
    > Bernd Strieder


    I would see this as a great opportunity, as there are - and there has
    been - a number of different package managers with different success
    rates. Maybe we could learn from their misconceptions and errors, and
    take the best parts of each manager to create a unified and universal
    package manager ie. to create something which will provide the
    greatest common dominator of the successful package managers.

    When I say, "unified and universal", I mean that the basic operations
    and "user experience" need to be similar to the ordinary desktop user.
    For the expert users, the different distros may provide some
    additional features that are needed for this specific distro.

    /TS

  3. Re: Universal Package Manager System for Linux?

    On 1 heinš, 22:26, Bernd Strieder
    wrote:
    > Hello,
    >
    > tsaar2...@yahoo.com wrote:
    > > As I see it, if Linux wants to be a major desktop operating system, it
    > > needs a simple AND unified on-click package management system, which
    > > is so simple that even my 80 year old grandmother is able to install
    > > applications and needed drivers on her system.

    >
    > There is no package system out there which is perfect, no commercial
    > systems and none of the opensource systems, all have had misconceptions
    > and errors from time to time. They are all work in progress. Most of
    > their differences originate in different goals of those writing the
    > management, of those packing the packages, of those using and
    > installing the packages. The biggest hindrance towards unification is
    > that most are satisfied with their current solution, and doing it even
    > better than to satisfaction is not possible. Your real task is to unify
    > developers, users and packagers in a way that they give up the specific
    > advantages of their current solution for the unification, and that will
    > not work as history tells. At its best it degrades into just another
    > package manager with its share of followers.
    >
    > Bernd Strieder


    I would see this as a great opportunity, as there are - and there has
    been - a number of different package managers with different success
    rates. Maybe we could learn from their misconceptions and errors, and
    take the best parts of each manager to create a unified and universal
    package manager ie. to create something which will provide the
    greatest common dominator of the successful package managers.

    When I say, "unified and universal", I mean that the basic operations
    and "user experience" need to be similar to the ordinary desktop user.
    For the expert users, the different distros may provide some
    additional features that are needed for this specific distro.

    /TS

  4. Re: Universal Package Manager System for Linux?

    On 3 heinš, 03:29, phil-news-nos...@ipal.net wrote:
    > In comp.os.linux.development.system tsaar2...@yahoo.com wrote:
    > | In my experience, the ordinary people feel, that Linux is for geeks
    > | only, and it is too complicated system for an ordinary person to
    > | install and use. Some distros (like *ubuntu) make installation process
    > | like a snap, although their disk partition process is still quite
    > | complicated, unless you want to use entire disk for the Linux.
    >
    > Linux PER SE really is for geeks only. Ubuntu is less so. Ubuntu is
    > built using Linux and other stuff like GNU tools.


    Well, Linux is only kernel and not very useful per se. In order to get
    system even boot to command line, you still need boot loader, initrd
    and either busybox or a set of GNU utilities. Then you have at least a
    running system with some capabilities (if you configured Kernel
    properly). Ubuntu and other distros has then added a set of packages
    that they consider useful for the user, apply some distro specific
    patches and settings, and basically this is a simple distribution. Of
    course these more popular distros come with support for 32- and 64-bit
    archs and possibly some other archs, too.

    > Microsoft could make an OS based on GNU/Linux if they wanted to. They
    > would have to release the source code, among other things. But it would
    > certainly be something that *I* would NOT want to use if they did this.
    > Why? Because I *like* to build my own ... my way. All that would be
    > different for me if Microsoft did this would be that Microsoft might
    > become a potential employer for lots of geeks like me (I could work for
    > a company that wanted me to build Linux systems for them _their_ way).


    I am not saying, that this package manager would not allow you to
    build and tweak your own system. On the contrary. If this package
    manager is done right (TM), this would make creating your own distro
    or subversion of existing distro more easy. I am after words
    "automatically" and "repeatibly", so that selecting packages, applying
    the patches and building the system could be easy for the expert
    users. This is definitely beyond what my 80-year old grandmother
    needs, but anyway, this should be something that the universal package
    manager should provide for the advanced and expert users.

    > Linux doesn't want anything. Some Linux people want it to be a major
    > desktop operating system. What *I* want is for hardware vendors to
    > make hardware that Linux works with.


    I agree.

    > That is inherintly a conflict (of interest). Many distros are made
    > for the purpose of exploring alternative ideas that may be incompatible
    > with whatever standard thing you want to impose.


    One-click is the basic user experience, but the advanced user should
    be able to get more features in command line mode.

    > You want to complicate people's lives by making them choose between
    > compiling from source vs. installing a pre-compiled binary? :-)


    No, I would like to see that basic users would still use and install
    the precompiled packages and binaries. But, if an advanced user need
    the source, he/she could have it easily.

    > | - Recompile and reinstall the driver automatically if the kernel
    > | version changes
    > | - Compile an application/driver from the general source, apply a
    > | distro specific patches, and install it automatically
    >
    > What about my own patches?


    The system should support your own patches too - of course. I am not
    an expert of package management by any means, but if I try to
    elaborate this situation here, so that someone might catch any errors
    in my thinking.

    In the beginning there is a thing called PACKAGE.X.Y.Z, which is a set
    of source files and, X.Y.Z is the version number and patch level. This
    package may also contain some dependencies ie. referencies to other
    packages. Then some distro DISTA decides to include this package into
    their distribution, so they make this original source code availabe to
    the expert distro users. This package may need some distro specific
    pacthes, and they will publish this set of patches, too. This distro
    may also have support for multiple processor architectures, so this
    package may also need some architecture specific patches, and they
    will publish this set of patches, too. At this point, distro will take
    the original source code, apply necessary patches and compile the
    package creating a binary, which is made available to the basic user
    via this one-click universal installer. The package manager will also
    take care of any depenecies and install any needed files too. As one
    could see, it is quite easy to build this package from the source as
    the source code is available with patches at different stages. And an
    expert user could apply his/her own set of patches and instruct the
    system to build and install the package.

    > | - Install (and optionally compile) any dependencies automatically
    >
    > That means someone has to track these. And they differ depending on
    > things like compile time options.


    True. The package managers usually do this.

    > What if a package will make use of something else *IF* it is present,
    > but happens to not be present right now. Then the system owner decides
    > to install that weak dependency later on. Would you want this package
    > that has the weak reference to it to also be recompiled?


    This mode is for experts only, not for the basic user. The basic user
    should use precompiled binaries or use the source used for the
    precompiled binaries.

    > | - Remove selected application and its dependencies
    >
    > That means these have to be tracked as installed.


    True, some package managers are doing this.

    > | - Take a snapshot of the current system state (applications and
    > | drivers)
    > | - Restore (rebuild) the system automatically to a given state
    >
    > You've gone way beyond what the "average Joe" user wants to even know
    > about. Many people I know don't care about OSes. They just want to
    > read their email and visit their regular web pages. And they also
    > want the the spammy popups to stop.


    Maybe I got too way out of line here, as a package manager should not
    be a substitute for a backup. However, some sort of snapshot could be
    useful, so that if installation breaks something, the system could be
    recovered from the distro using the packages installed at the time of
    the snapshot.

    > So as soo as you come out with all this (assuming you find some geeks to
    > go along with it and do all the detail work for you), someone else will
    > have a similar, but incompatibly different, idea. And they will say your
    > idea needs to be scrapped.


    Consensus and compromise are the key words here. If the basic idea is
    good and simple, the user experience could be kept the same (one-
    click).

    > Linux is about choice. There are plenty of package manage systems out there.
    > Why haven't you chosen one of them? If none are to your liking, can you say
    > why for a few specific ones?


    I am not saying that existing package managers aren't good (they are
    doing their job), I am trying to say that an average user should see
    identical package manager interface and have identical user experience
    no matter which distribution one uses. And installing packages and
    upgrading the system should be made as easy as possible to an average
    user - ultimately requiring only one mouse click per package/
    application.

    /TS

  5. Re: Universal Package Manager System for Linux?

    On 3 heinš, 03:29, phil-news-nos...@ipal.net wrote:
    > In comp.os.linux.development.system tsaar2...@yahoo.com wrote:
    > | In my experience, the ordinary people feel, that Linux is for geeks
    > | only, and it is too complicated system for an ordinary person to
    > | install and use. Some distros (like *ubuntu) make installation process
    > | like a snap, although their disk partition process is still quite
    > | complicated, unless you want to use entire disk for the Linux.
    >
    > Linux PER SE really is for geeks only. Ubuntu is less so. Ubuntu is
    > built using Linux and other stuff like GNU tools.


    Well, Linux is only kernel and not very useful per se. In order to get
    system even boot to command line, you still need boot loader, initrd
    and either busybox or a set of GNU utilities. Then you have at least a
    running system with some capabilities (if you configured Kernel
    properly). Ubuntu and other distros has then added a set of packages
    that they consider useful for the user, apply some distro specific
    patches and settings, and basically this is a simple distribution. Of
    course these more popular distros come with support for 32- and 64-bit
    archs and possibly some other archs, too.

    > Microsoft could make an OS based on GNU/Linux if they wanted to. They
    > would have to release the source code, among other things. But it would
    > certainly be something that *I* would NOT want to use if they did this.
    > Why? Because I *like* to build my own ... my way. All that would be
    > different for me if Microsoft did this would be that Microsoft might
    > become a potential employer for lots of geeks like me (I could work for
    > a company that wanted me to build Linux systems for them _their_ way).


    I am not saying, that this package manager would not allow you to
    build and tweak your own system. On the contrary. If this package
    manager is done right (TM), this would make creating your own distro
    or subversion of existing distro more easy. I am after words
    "automatically" and "repeatibly", so that selecting packages, applying
    the patches and building the system could be easy for the expert
    users. This is definitely beyond what my 80-year old grandmother
    needs, but anyway, this should be something that the universal package
    manager should provide for the advanced and expert users.

    > Linux doesn't want anything. Some Linux people want it to be a major
    > desktop operating system. What *I* want is for hardware vendors to
    > make hardware that Linux works with.


    I agree.

    > That is inherintly a conflict (of interest). Many distros are made
    > for the purpose of exploring alternative ideas that may be incompatible
    > with whatever standard thing you want to impose.


    One-click is the basic user experience, but the advanced user should
    be able to get more features in command line mode.

    > You want to complicate people's lives by making them choose between
    > compiling from source vs. installing a pre-compiled binary? :-)


    No, I would like to see that basic users would still use and install
    the precompiled packages and binaries. But, if an advanced user need
    the source, he/she could have it easily.

    > | - Recompile and reinstall the driver automatically if the kernel
    > | version changes
    > | - Compile an application/driver from the general source, apply a
    > | distro specific patches, and install it automatically
    >
    > What about my own patches?


    The system should support your own patches too - of course. I am not
    an expert of package management by any means, but if I try to
    elaborate this situation here, so that someone might catch any errors
    in my thinking.

    In the beginning there is a thing called PACKAGE.X.Y.Z, which is a set
    of source files and, X.Y.Z is the version number and patch level. This
    package may also contain some dependencies ie. referencies to other
    packages. Then some distro DISTA decides to include this package into
    their distribution, so they make this original source code availabe to
    the expert distro users. This package may need some distro specific
    pacthes, and they will publish this set of patches, too. This distro
    may also have support for multiple processor architectures, so this
    package may also need some architecture specific patches, and they
    will publish this set of patches, too. At this point, distro will take
    the original source code, apply necessary patches and compile the
    package creating a binary, which is made available to the basic user
    via this one-click universal installer. The package manager will also
    take care of any depenecies and install any needed files too. As one
    could see, it is quite easy to build this package from the source as
    the source code is available with patches at different stages. And an
    expert user could apply his/her own set of patches and instruct the
    system to build and install the package.

    > | - Install (and optionally compile) any dependencies automatically
    >
    > That means someone has to track these. And they differ depending on
    > things like compile time options.


    True. The package managers usually do this.

    > What if a package will make use of something else *IF* it is present,
    > but happens to not be present right now. Then the system owner decides
    > to install that weak dependency later on. Would you want this package
    > that has the weak reference to it to also be recompiled?


    This mode is for experts only, not for the basic user. The basic user
    should use precompiled binaries or use the source used for the
    precompiled binaries.

    > | - Remove selected application and its dependencies
    >
    > That means these have to be tracked as installed.


    True, some package managers are doing this.

    > | - Take a snapshot of the current system state (applications and
    > | drivers)
    > | - Restore (rebuild) the system automatically to a given state
    >
    > You've gone way beyond what the "average Joe" user wants to even know
    > about. Many people I know don't care about OSes. They just want to
    > read their email and visit their regular web pages. And they also
    > want the the spammy popups to stop.


    Maybe I got too way out of line here, as a package manager should not
    be a substitute for a backup. However, some sort of snapshot could be
    useful, so that if installation breaks something, the system could be
    recovered from the distro using the packages installed at the time of
    the snapshot.

    > So as soo as you come out with all this (assuming you find some geeks to
    > go along with it and do all the detail work for you), someone else will
    > have a similar, but incompatibly different, idea. And they will say your
    > idea needs to be scrapped.


    Consensus and compromise are the key words here. If the basic idea is
    good and simple, the user experience could be kept the same (one-
    click).

    > Linux is about choice. There are plenty of package manage systems out there.
    > Why haven't you chosen one of them? If none are to your liking, can you say
    > why for a few specific ones?


    I am not saying that existing package managers aren't good (they are
    doing their job), I am trying to say that an average user should see
    identical package manager interface and have identical user experience
    no matter which distribution one uses. And installing packages and
    upgrading the system should be made as easy as possible to an average
    user - ultimately requiring only one mouse click per package/
    application.

    /TS

  6. Re: Universal Package Manager System for Linux?

    In comp.os.linux.development.system Bernhard Agthe wrote:
    | Hi,
    |
    |> |> One thing I've often wondered about it why installing Windows programs
    |> |> takes to long? It easily takes 5 minutes to install just a small
    |> |> application, not including the almost obligatory reboot.
    |
    | Including the windows installer itself ;-) But not all Programs require
    | a restart anymore...

    Some do. Some don't.


    |> | I'm glad you noticed that too. A Microsoft Engineer told me that the
    |> | reboot problem had been fixed in XP, so software packages don't need to reboot
    |> | following installation. However, I still find that Micros~1dows based
    |> | computers require a reboot when I put new software on (even if the
    |> | computer does not go blue screen).
    |
    | Well, Windows itself might be comfortable wit not rebooting after an
    | install, but many installation programs have the reboot as part of
    | themselves. Windows won't interfere, if the developer of an application
    | feels the computer needs to be restarted after the installation. And
    | there are some cases, where settings must be made at reboot time (via a
    | special, elaborate registry mechanism) or settings only take effect
    | *reliably* after reboot... This has to do with the integration of
    | Operating system, run-time libraries, graphical system, user interface
    | and others.

    Of coure many times a reboot really is essential. But my point is a
    different one: when a reboot is not required and a restart of (some)
    apps is all that is needed, doing it _as_ a reboot makes more sense
    to the average user. They are accustomed to rebooting Windows.


    |> I sometimes reboot Linux just because it is easier. I'm sure Windows could
    |> kill all the processes using something that got changed. But people would
    |> have a hard time understanding why their Word window just closed because some
    |> other program was installed. Rebooting is done, at least in part, because
    |> that way people _expect_ everything to be restarted. if many programs were
    |> killed or restarted without a reboot, they might think something is wrong.
    |
    | Well, I never reboot Linux on purpose, everything requiring a reboot is
    | a Kernel update and the reboot can wait until I shut down my computer
    | for the night, anyway.

    I do if I change things and decide it is easier to reboot than deal with
    the inconsistencies that can be left behind. Also, if I change any init
    script, I reboot now or real soon now so I don't get a lingering surprise
    a month later wondering why something didn't start up right.

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  7. Re: Universal Package Manager System for Linux?

    In comp.os.linux.development.system Bernhard Agthe wrote:
    | Hi,
    |
    |> |> One thing I've often wondered about it why installing Windows programs
    |> |> takes to long? It easily takes 5 minutes to install just a small
    |> |> application, not including the almost obligatory reboot.
    |
    | Including the windows installer itself ;-) But not all Programs require
    | a restart anymore...

    Some do. Some don't.


    |> | I'm glad you noticed that too. A Microsoft Engineer told me that the
    |> | reboot problem had been fixed in XP, so software packages don't need to reboot
    |> | following installation. However, I still find that Micros~1dows based
    |> | computers require a reboot when I put new software on (even if the
    |> | computer does not go blue screen).
    |
    | Well, Windows itself might be comfortable wit not rebooting after an
    | install, but many installation programs have the reboot as part of
    | themselves. Windows won't interfere, if the developer of an application
    | feels the computer needs to be restarted after the installation. And
    | there are some cases, where settings must be made at reboot time (via a
    | special, elaborate registry mechanism) or settings only take effect
    | *reliably* after reboot... This has to do with the integration of
    | Operating system, run-time libraries, graphical system, user interface
    | and others.

    Of coure many times a reboot really is essential. But my point is a
    different one: when a reboot is not required and a restart of (some)
    apps is all that is needed, doing it _as_ a reboot makes more sense
    to the average user. They are accustomed to rebooting Windows.


    |> I sometimes reboot Linux just because it is easier. I'm sure Windows could
    |> kill all the processes using something that got changed. But people would
    |> have a hard time understanding why their Word window just closed because some
    |> other program was installed. Rebooting is done, at least in part, because
    |> that way people _expect_ everything to be restarted. if many programs were
    |> killed or restarted without a reboot, they might think something is wrong.
    |
    | Well, I never reboot Linux on purpose, everything requiring a reboot is
    | a Kernel update and the reboot can wait until I shut down my computer
    | for the night, anyway.

    I do if I change things and decide it is easier to reboot than deal with
    the inconsistencies that can be left behind. Also, if I change any init
    script, I reboot now or real soon now so I don't get a lingering surprise
    a month later wondering why something didn't start up right.

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  8. Re: Universal Package Manager System for Linux?

    Hi,

    > | Including the windows installer itself ;-) But not all Programs require
    > | a restart anymore...
    >
    > Some do. Some don't.


    Right, but there is no consistency as to the type of application. If I
    install a driver and are prompted to restart Windows, I do understand
    it. Yesterday I had a keyboard driver which didn't require a reboot - I
    was happy.

    If, however, I install a simple application with no impact on the system
    config and are prompted to restart Windows, this is something I do not
    accept gladly. Just look at any common Linux system: Installing a new
    driver (kernel module) you don't even think about rebooting, just insmod
    driver, done. With any application I would even be offended if the
    installation required a reboot.

    > Of coure many times a reboot really is essential. But my point is a
    > different one: when a reboot is not required and a restart of (some)
    > apps is all that is needed, doing it _as_ a reboot makes more sense
    > to the average user. They are accustomed to rebooting Windows.


    Why would you want to restart your OpenOffice (or whatever) if you
    installed a new browser version? Sorry mate, you don't make much sense.
    Anything beyond a restart of the updated or newly installed application
    is useless waste of time and nerves.

    > I do if I change things and decide it is easier to reboot than deal with
    > the inconsistencies that can be left behind. Also, if I change any init
    > script, I reboot now or real soon now so I don't get a lingering surprise
    > a month later wondering why something didn't start up right.


    Wait, if you change the startup configuration on purpose, you are likely
    to test it right away, but even then it's enough to restart the service
    linked to that script or to change the run-level. The only reason I know
    to reboot linux is a change to the kernel or to the boot loader.
    Everything else *can* be done with the system up. Because I do shut down
    my computer at night, even a kernel-update is no reason for an immediate
    reboot for me.

    The original question was for an installer. Rebooting seems to be part
    of installation in the Windos world, but it never has been in the linux
    world. I do have thorough experience with two different package
    managers, both do work as anyone would expect. Actually, by standing in
    direct competition to each other, they also get improved.

    Ciao...

    PS: the usual disclaimer...



  9. Re: Universal Package Manager System for Linux?

    Hi,

    > | Including the windows installer itself ;-) But not all Programs require
    > | a restart anymore...
    >
    > Some do. Some don't.


    Right, but there is no consistency as to the type of application. If I
    install a driver and are prompted to restart Windows, I do understand
    it. Yesterday I had a keyboard driver which didn't require a reboot - I
    was happy.

    If, however, I install a simple application with no impact on the system
    config and are prompted to restart Windows, this is something I do not
    accept gladly. Just look at any common Linux system: Installing a new
    driver (kernel module) you don't even think about rebooting, just insmod
    driver, done. With any application I would even be offended if the
    installation required a reboot.

    > Of coure many times a reboot really is essential. But my point is a
    > different one: when a reboot is not required and a restart of (some)
    > apps is all that is needed, doing it _as_ a reboot makes more sense
    > to the average user. They are accustomed to rebooting Windows.


    Why would you want to restart your OpenOffice (or whatever) if you
    installed a new browser version? Sorry mate, you don't make much sense.
    Anything beyond a restart of the updated or newly installed application
    is useless waste of time and nerves.

    > I do if I change things and decide it is easier to reboot than deal with
    > the inconsistencies that can be left behind. Also, if I change any init
    > script, I reboot now or real soon now so I don't get a lingering surprise
    > a month later wondering why something didn't start up right.


    Wait, if you change the startup configuration on purpose, you are likely
    to test it right away, but even then it's enough to restart the service
    linked to that script or to change the run-level. The only reason I know
    to reboot linux is a change to the kernel or to the boot loader.
    Everything else *can* be done with the system up. Because I do shut down
    my computer at night, even a kernel-update is no reason for an immediate
    reboot for me.

    The original question was for an installer. Rebooting seems to be part
    of installation in the Windos world, but it never has been in the linux
    world. I do have thorough experience with two different package
    managers, both do work as anyone would expect. Actually, by standing in
    direct competition to each other, they also get improved.

    Ciao...

    PS: the usual disclaimer...



  10. Re: Universal Package Manager System for Linux?

    In comp.os.linux.development.system Bernhard Agthe wrote:
    | Hi,
    |
    |> | Including the windows installer itself ;-) But not all Programs require
    |> | a restart anymore...
    |>
    |> Some do. Some don't.
    |
    | Right, but there is no consistency as to the type of application. If I
    | install a driver and are prompted to restart Windows, I do understand
    | it. Yesterday I had a keyboard driver which didn't require a reboot - I
    | was happy.

    And if that driver being installed did not require any application to be
    restarted, all is well.


    | If, however, I install a simple application with no impact on the system
    | config and are prompted to restart Windows, this is something I do not
    | accept gladly. Just look at any common Linux system: Installing a new
    | driver (kernel module) you don't even think about rebooting, just insmod
    | driver, done. With any application I would even be offended if the
    | installation required a reboot.

    Sometimes these applications need to update a library. The library may be
    in use by another application. Various restrictions might exist, and if
    not enforced might even do bad things in the interim like corrupt the
    registry. There could be problems if two seperate library copies are
    running and accessing things. You might need to restart all applications
    using that library to avoid the issue. In cases like this, it is simpler
    to require a reboot than to even scan around to see if any conflicting
    application is even running.

    I prefer to be in control of my own computer so I like being able to install
    things without restarting (even if in Windows). But most people would not
    even want to think about the level of detail I work with regularly. For them
    a reboot is simplicity, even if annoying, compared to the possible alternative.


    |> Of coure many times a reboot really is essential. But my point is a
    |> different one: when a reboot is not required and a restart of (some)
    |> apps is all that is needed, doing it _as_ a reboot makes more sense
    |> to the average user. They are accustomed to rebooting Windows.
    |
    | Why would you want to restart your OpenOffice (or whatever) if you
    | installed a new browser version? Sorry mate, you don't make much sense.
    | Anything beyond a restart of the updated or newly installed application
    | is useless waste of time and nerves.

    Assuming OpenOffice is not sharing any libraries that got upgraded or even
    downgraded by the new browser, you should not want to restart OpenOffice.
    But the installer might be designed on the basis that most people could be
    using something, such as Microsoft Office, that shares components with the
    browser (there are a lot of them) that might be updated. That application
    or possibly many others (including third party applications) might need to
    be restarted as a result of the browser install/upgrade. Rebooting is a
    simplification of that for the simple minded people that make up the vast
    majority of Microsoft Windows users.


    |> I do if I change things and decide it is easier to reboot than deal with
    |> the inconsistencies that can be left behind. Also, if I change any init
    |> script, I reboot now or real soon now so I don't get a lingering surprise
    |> a month later wondering why something didn't start up right.
    |
    | Wait, if you change the startup configuration on purpose, you are likely
    | to test it right away, but even then it's enough to restart the service
    | linked to that script or to change the run-level. The only reason I know
    | to reboot linux is a change to the kernel or to the boot loader.

    Sometimes I want specific things restarted. Sometimes there are many.
    I do elect to do a reboot simply _becasue_ in many cases it is the easier
    path to get to where I want to be, even though I could have gotten there
    (and know how to) with manual restarts of some thing.


    | Everything else *can* be done with the system up. Because I do shut down
    | my computer at night, even a kernel-update is no reason for an immediate
    | reboot for me.

    Then you might be surprised to find a malfunctioning system in the morning
    because of a typo when rebuilding the kernel (I assume that you, like me,
    do not rebuild kernels most of the time just for the sake of rebuilding it,
    but do have some reason to rebuild it).

    I do leave my computers on 24x7. Partly its for hardware stability (avoid
    thermal changes). Partly its for things in progress (several web sites open,
    ongoing edits, Usenet, etc). I run 60 text mode virtual consoles, all of
    which are logged in, and often with most of them having something there.
    I also run 3 instances of X Windows with 32 virtual desktops each, and an
    average of 20 to 40 windows open. So I don't take rebooting too lightly.
    It depends on how long the machine has been up. Over the past week I did
    perhaps 50 reboots because it was a whole new machine and I was making many
    tweaks to adjust for the new hardware, etc. I still don't have the audio
    working on this (it's recognized, but even with all software and hardware
    volume settings at max, I can barely hear the music being played).


    | The original question was for an installer. Rebooting seems to be part
    | of installation in the Windos world, but it never has been in the linux
    | world. I do have thorough experience with two different package
    | managers, both do work as anyone would expect. Actually, by standing in
    | direct competition to each other, they also get improved.

    There's less reason for rebooting to be in the Linux world. But at install
    time, I'll be rebooting at least once. If I adjust anything like init scripts,
    it's probably many reboots for me.

    FYI, I'm running my home machines on init script *I* wrote entirely myself from
    scratch (and inittab, too).

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  11. Re: Universal Package Manager System for Linux?

    In comp.os.linux.development.system Bernhard Agthe wrote:
    | Hi,
    |
    |> | Including the windows installer itself ;-) But not all Programs require
    |> | a restart anymore...
    |>
    |> Some do. Some don't.
    |
    | Right, but there is no consistency as to the type of application. If I
    | install a driver and are prompted to restart Windows, I do understand
    | it. Yesterday I had a keyboard driver which didn't require a reboot - I
    | was happy.

    And if that driver being installed did not require any application to be
    restarted, all is well.


    | If, however, I install a simple application with no impact on the system
    | config and are prompted to restart Windows, this is something I do not
    | accept gladly. Just look at any common Linux system: Installing a new
    | driver (kernel module) you don't even think about rebooting, just insmod
    | driver, done. With any application I would even be offended if the
    | installation required a reboot.

    Sometimes these applications need to update a library. The library may be
    in use by another application. Various restrictions might exist, and if
    not enforced might even do bad things in the interim like corrupt the
    registry. There could be problems if two seperate library copies are
    running and accessing things. You might need to restart all applications
    using that library to avoid the issue. In cases like this, it is simpler
    to require a reboot than to even scan around to see if any conflicting
    application is even running.

    I prefer to be in control of my own computer so I like being able to install
    things without restarting (even if in Windows). But most people would not
    even want to think about the level of detail I work with regularly. For them
    a reboot is simplicity, even if annoying, compared to the possible alternative.


    |> Of coure many times a reboot really is essential. But my point is a
    |> different one: when a reboot is not required and a restart of (some)
    |> apps is all that is needed, doing it _as_ a reboot makes more sense
    |> to the average user. They are accustomed to rebooting Windows.
    |
    | Why would you want to restart your OpenOffice (or whatever) if you
    | installed a new browser version? Sorry mate, you don't make much sense.
    | Anything beyond a restart of the updated or newly installed application
    | is useless waste of time and nerves.

    Assuming OpenOffice is not sharing any libraries that got upgraded or even
    downgraded by the new browser, you should not want to restart OpenOffice.
    But the installer might be designed on the basis that most people could be
    using something, such as Microsoft Office, that shares components with the
    browser (there are a lot of them) that might be updated. That application
    or possibly many others (including third party applications) might need to
    be restarted as a result of the browser install/upgrade. Rebooting is a
    simplification of that for the simple minded people that make up the vast
    majority of Microsoft Windows users.


    |> I do if I change things and decide it is easier to reboot than deal with
    |> the inconsistencies that can be left behind. Also, if I change any init
    |> script, I reboot now or real soon now so I don't get a lingering surprise
    |> a month later wondering why something didn't start up right.
    |
    | Wait, if you change the startup configuration on purpose, you are likely
    | to test it right away, but even then it's enough to restart the service
    | linked to that script or to change the run-level. The only reason I know
    | to reboot linux is a change to the kernel or to the boot loader.

    Sometimes I want specific things restarted. Sometimes there are many.
    I do elect to do a reboot simply _becasue_ in many cases it is the easier
    path to get to where I want to be, even though I could have gotten there
    (and know how to) with manual restarts of some thing.


    | Everything else *can* be done with the system up. Because I do shut down
    | my computer at night, even a kernel-update is no reason for an immediate
    | reboot for me.

    Then you might be surprised to find a malfunctioning system in the morning
    because of a typo when rebuilding the kernel (I assume that you, like me,
    do not rebuild kernels most of the time just for the sake of rebuilding it,
    but do have some reason to rebuild it).

    I do leave my computers on 24x7. Partly its for hardware stability (avoid
    thermal changes). Partly its for things in progress (several web sites open,
    ongoing edits, Usenet, etc). I run 60 text mode virtual consoles, all of
    which are logged in, and often with most of them having something there.
    I also run 3 instances of X Windows with 32 virtual desktops each, and an
    average of 20 to 40 windows open. So I don't take rebooting too lightly.
    It depends on how long the machine has been up. Over the past week I did
    perhaps 50 reboots because it was a whole new machine and I was making many
    tweaks to adjust for the new hardware, etc. I still don't have the audio
    working on this (it's recognized, but even with all software and hardware
    volume settings at max, I can barely hear the music being played).


    | The original question was for an installer. Rebooting seems to be part
    | of installation in the Windos world, but it never has been in the linux
    | world. I do have thorough experience with two different package
    | managers, both do work as anyone would expect. Actually, by standing in
    | direct competition to each other, they also get improved.

    There's less reason for rebooting to be in the Linux world. But at install
    time, I'll be rebooting at least once. If I adjust anything like init scripts,
    it's probably many reboots for me.

    FYI, I'm running my home machines on init script *I* wrote entirely myself from
    scratch (and inittab, too).

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  12. Re: Universal Package Manager System for Linux?

    Phil Howard writes:
    > Assuming OpenOffice is not sharing any libraries that got upgraded or
    > even downgraded by the new browser, you should not want to restart
    > OpenOffice. But the installer might be designed on the basis that most
    > people could be using something, such as Microsoft Office, that shares
    > components with the browser (there are a lot of them) that might be
    > updated. That application or possibly many others (including third party
    > applications) might need to be restarted as a result of the browser
    > install/upgrade.


    Upgrading a Linux library will have no effect on running applications that
    use that library.
    --
    John Hasler
    john@dhh.gt.org
    Dancing Horse Hill
    Elmwood, WI USA

  13. Re: Universal Package Manager System for Linux?

    On 2008-07-01, tsaar2003@yahoo.com wrote:

    > In my opinion, the ultimate goal should be that each and every main
    > Linux (and BSD) distro would use the same universal and unified
    > package management system, so that the end-user would always have the
    > same experience no matter what distro one uses.


    The distros are supposed to be different.

    this is what GPL is all about.





    Bye.
    Jasen

  14. Re: Universal Package Manager System for Linux?

    On 2008-07-01, tsaar2003@yahoo.com wrote:

    > In my opinion, the ultimate goal should be that each and every main
    > Linux (and BSD) distro would use the same universal and unified
    > package management system, so that the end-user would always have the
    > same experience no matter what distro one uses.


    The distros are supposed to be different.

    this is what GPL is all about.





    Bye.
    Jasen

  15. Re: Universal Package Manager System for Linux?

    On 2008-07-02, Jerry Peters wrote:

    > One thing I've often wondered about it why installing Windows programs
    > takes to long? It easily takes 5 minutes to install just a small
    > application, not including the almost obligatory reboot.


    this is usually because the programmers don't know how to tell windows to
    reinitialise the bits it needs to reinitialise.

    But sometimes it is also due to the way windows file locking works.

    In linux you can delete the binary of a running process and replace it
    with a new one - the old binary hangs around as an anonymous inode
    until it's finally closed, under windows if the binary is in use it's
    set in stone and can't be replaced.

    If the binary is a popular DLL this can be really inconvenient.

    Bye.
    Jasen

  16. Re: Universal Package Manager System for Linux?

    On 2008-07-02, Jerry Peters wrote:

    > One thing I've often wondered about it why installing Windows programs
    > takes to long? It easily takes 5 minutes to install just a small
    > application, not including the almost obligatory reboot.


    this is usually because the programmers don't know how to tell windows to
    reinitialise the bits it needs to reinitialise.

    But sometimes it is also due to the way windows file locking works.

    In linux you can delete the binary of a running process and replace it
    with a new one - the old binary hangs around as an anonymous inode
    until it's finally closed, under windows if the binary is in use it's
    set in stone and can't be replaced.

    If the binary is a popular DLL this can be really inconvenient.

    Bye.
    Jasen

  17. Re: Universal Package Manager System for Linux?

    On 2008-07-03, Rainer Weikusat wrote:
    > John Hasler writes:
    >> Phil Howard writes:
    >>> I get around the problem by installing as much software as I can the
    >>> first time around.

    >>
    >> What problem?
    >>
    >>> I install it anyway. Disk space is cheap. If I need it, it won't kill
    >>> something else to start using it.

    >>
    >> What Linux applications have you found to kill things when installed?

    >
    > This is not an experience of me, either. I am Debian user since 1998
    > (SuSE and RH before that) and no new installation of anything or
    > upgrade of an existing something has ever terminated an application I
    > was using on its own.


    various library upgrades will restart services, but this never seems
    to effect applications that are using those services - most apps can
    handle the service being restarted

    If you install gpm (a console-based service) it offers (and
    reccomends) restarting X.

    Bye.
    Jasen











  18. Re: Universal Package Manager System for Linux?

    In comp.os.linux.development.system Jasen Betts wrote:
    | On 2008-07-02, Jerry Peters wrote:
    |
    |> One thing I've often wondered about it why installing Windows programs
    |> takes to long? It easily takes 5 minutes to install just a small
    |> application, not including the almost obligatory reboot.
    |
    | this is usually because the programmers don't know how to tell windows to
    | reinitialise the bits it needs to reinitialise.
    |
    | But sometimes it is also due to the way windows file locking works.
    |
    | In linux you can delete the binary of a running process and replace it
    | with a new one - the old binary hangs around as an anonymous inode
    | until it's finally closed, under windows if the binary is in use it's
    | set in stone and can't be replaced.
    |
    | If the binary is a popular DLL this can be really inconvenient.

    This is why some of the installation gets scheduled to be finished during reboot.

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  19. Re: Universal Package Manager System for Linux?

    In comp.os.linux.development.system Jasen Betts wrote:
    | On 2008-07-02, Jerry Peters wrote:
    |
    |> One thing I've often wondered about it why installing Windows programs
    |> takes to long? It easily takes 5 minutes to install just a small
    |> application, not including the almost obligatory reboot.
    |
    | this is usually because the programmers don't know how to tell windows to
    | reinitialise the bits it needs to reinitialise.
    |
    | But sometimes it is also due to the way windows file locking works.
    |
    | In linux you can delete the binary of a running process and replace it
    | with a new one - the old binary hangs around as an anonymous inode
    | until it's finally closed, under windows if the binary is in use it's
    | set in stone and can't be replaced.
    |
    | If the binary is a popular DLL this can be really inconvenient.

    This is why some of the installation gets scheduled to be finished during reboot.

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  20. Re: Universal Package Manager System for Linux?

    Jasen writes:
    > If you install gpm (a console-based service) it offers (and
    > reccomends) restarting X.


    This is because it used to be necessary to use gpm as a repeater for X in
    order to get gpm and X to play together nicely. I believe (but am not
    certain) that this is no longer necessary.
    --
    John Hasler
    john@dhh.gt.org
    Dancing Horse Hill
    Elmwood, WI USA

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast