Professional Web Applications Themes

kernel is always too big.... - Linux Setup, Configuration & Administration

Dear group, i know, i am another one's kernel too big, yes. Thats right... It does no matter, i can - only do a "make menuconfig", the menue starts, and i quit the makeconfig, in deed, i configure nothing... - disable things like usb, wlan, sound, and so on... - make many modules my kernel is between 2.2 MB and 2.8 MB big. I do the following steps: make menuconfig for config kernelparameters or only for having a makefile make dep for depend. make clean cleaning make bzImage for a zipped kernel.... have anyone ideas??? thanks, nice weekend. tom...

  1. #1

    Default kernel is always too big....

    Dear group,

    i know, i am another one's kernel too big, yes. Thats right...

    It does no matter, i can

    - only do a "make menuconfig", the menue starts, and i quit the
    makeconfig, in deed, i configure nothing...

    - disable things like usb, wlan, sound, and so on...

    - make many modules

    my kernel is between 2.2 MB and 2.8 MB big.

    I do the following steps:
    make menuconfig for config kernelparameters or only for having a
    makefile
    make dep for depend.
    make clean cleaning

    make bzImage for a zipped kernel....


    have anyone ideas???

    thanks, nice weekend.

    tom
    T Guest

  2. #2

    Default Re: kernel is always too big....

    T wrote:
    > my kernel is between 2.2 MB and 2.8 MB big.
    > I do the following steps:
    > make menuconfig for config kernelparameters or only for having a
    > makefile
    > make dep for depend.
    > make clean cleaning
    >
    > make bzImage for a zipped kernel....
    Hmmm. Very weird order to do things. I'd use the following order:

    make clean
    make menuconfig
    make dep bzImage modules
    make modules_install install

    -Timo

    --
    Timo Voipio | Helsinki, Finland | ICBM at: 60 11.800 N 024 52.760 E
    GeekCode ver 3: GU>CC d s-: a--- C++ UL(+)$>+++$ P+>+++ L++(+) E- W++ N++
    o? K? w O M- V- PS PE Y+ PGP+ t 5++ X R tv- b++(++++) DI+ D G e- h! r !y

    Timo Voipio Guest

  3. #3

    Default Re: kernel is always too big....

    T <dejabluefiremail.de> wrote:
    > my kernel is between 2.2 MB and 2.8 MB big.
    Well, that's about 3 times too big.

    > I do the following steps:
    > make menuconfig for config kernelparameters or only for having a
    > makefile
    > make dep for depend.
    > make clean cleaning
    > make bzImage for a zipped kernel....
    And did you then USE the bzImage, or something else altogether? A
    passing idiot would imagine that you mistakenly used something else.
    The idiot would tend to believe that even more, since you carefully
    avoid telling us what you used as the kernel image.
    > have anyone ideas???
    You do. Start thinking.

    Peter
    Peter T. Breuer Guest

  4. #4

    Default Re: kernel is always too big....

    Dave Uhring <daveuhring> wrote:
    > On Fri, 18 Jul 2003 22:15:39 +0200, Peter T. Breuer wrote:
    >> T <dejabluefiremail.de> wrote:
    >>> my kernel is between 2.2 MB and 2.8 MB big.
    >>
    >> Well, that's about 3 times too big.
    > Lot smaller than my vmlinuz:
    > -rwxr-xr-x 1 root root 3921955 Jun 19 21:08 vmlinux
    > and only twice the size of a kernel built to support XFS and no modules
    > required:
    > -rw-r--r-- 1 root root 1459916 Jun 19 21:08 vmlinuz-2.4.21-xfs
    betty:/boot% ls -lSr vm*
    -rw-r--r-- 1 root 557214 Jan 21 2002 vmlinuz-2.2.20-SMP
    -rw-r--r-- 1 root 665462 Jan 27 2002 vmlinuz-2.2.18pre18-SMP
    -rw-r--r-- 1 root 829425 Sep 25 2002 vmlinuz-2.5.31-SMP-test
    -rw-r--r-- 1 root 849483 Sep 2 2002 vmlinuz-2.5.31-SMP
    -rw-r--r-- 1 root 890188 Jan 14 2003 vmlinuz-2.4.19-SMP-xfs
    -rw-r--r-- 1 root 914979 Jan 14 2002 vmlinuz-2.4.17rc2-xfs-swsusp
    -rw-r--r-- 1 root 939515 Jan 23 2002 vmlinuz-2.4.8-SMP-xfs.lkcd
    -rw-r--r-- 1 root 946396 Dec 21 2001 vmlinuz-2.4.16-SMP-xfs
    -rw-r--r-- 1 root 983954 Jul 30 2002 vmlinuz-2.4.17rc2-SMP-xfs-tosh_acpi
    -rw-r--r-- 1 root 1000702 Oct 29 2002 vmlinuz-2.5.44-SMP
    -rw-r--r-- 1 root 1007429 Nov 9 2002 vmlinuz-2.5.46-SMP
    -rw-r--r-- 1 root 1008821 Jan 9 2003 vmlinuz-2.4.20-SMP-xfs
    -rw-r--r-- 1 root 1010794 Nov 12 2002 vmlinuz-2.5.47-SMP
    -rw-r--r-- 1 root 1052787 Mar 9 09:02 vmlinuz-2.5.64-SMP


    Peter
    Peter T. Breuer Guest

  5. #5

    Default Re: kernel is always too big....

    On Fri, 18 Jul 2003 22:59:35 +0200, Peter T. Breuer wrote:
    > betty:/boot% ls -lSr vm*
    > -rw-r--r-- 1 root 557214 Jan 21 2002 vmlinuz-2.2.20-SMP
    > -rw-r--r-- 1 root 665462 Jan 27 2002 vmlinuz-2.2.18pre18-SMP
    > -rw-r--r-- 1 root 829425 Sep 25 2002 vmlinuz-2.5.31-SMP-test
    > -rw-r--r-- 1 root 849483 Sep 2 2002 vmlinuz-2.5.31-SMP
    > -rw-r--r-- 1 root 890188 Jan 14 2003 vmlinuz-2.4.19-SMP-xfs
    > -rw-r--r-- 1 root 914979 Jan 14 2002 vmlinuz-2.4.17rc2-xfs-swsusp
    > -rw-r--r-- 1 root 939515 Jan 23 2002 vmlinuz-2.4.8-SMP-xfs.lkcd
    > -rw-r--r-- 1 root 946396 Dec 21 2001 vmlinuz-2.4.16-SMP-xfs
    > -rw-r--r-- 1 root 983954 Jul 30 2002 vmlinuz-2.4.17rc2-SMP-xfs-tosh_acpi
    > -rw-r--r-- 1 root 1000702 Oct 29 2002 vmlinuz-2.5.44-SMP
    > -rw-r--r-- 1 root 1007429 Nov 9 2002 vmlinuz-2.5.46-SMP
    > -rw-r--r-- 1 root 1008821 Jan 9 2003 vmlinuz-2.4.20-SMP-xfs
    > -rw-r--r-- 1 root 1010794 Nov 12 2002 vmlinuz-2.5.47-SMP
    > -rw-r--r-- 1 root 1052787 Mar 9 09:02 vmlinuz-2.5.64-SMP
    I'm surprised you keep such old versions around; you don't use them, do
    you?

    Your 2.4.20-SMP-xfs kernel is surprisingly small. Did you build device
    support as modules? The kernel whose size I posted has full support for
    all devices on the box where it runs, including SCSI disks and tape with
    an Adaptec 2940UW controller.

    Dave Uhring Guest

  6. #6

    Default Re: kernel is always too big....

    On Fri, 18 Jul 2003 23:52:47 +0200, Peter T. Breuer wrote:
    > It's the one I suse most often (this is my portable). It has most stuff
    > as modules. Umm .. let me clear out the alsa sound moudles ..
    >
    > betty:/boot% /sbin/lsmod
    [snip list of modules ]

    On my Slackware system:

    [linux]# lsmod
    Module Size Used by Not tainted
    via686a 8096 0
    i2c-proc 6992 0 [via686a]
    i2c-isa 1160 0 (unused)
    i2c-dev 4132 0 (unused)
    i2c-viapro 3984 0 (unused)
    i2c-core 14472 0 [via686a i2c-proc i2c-isa i2c-dev i2c-viapro]

    Can't build lm-sensors into the kernel ;-) Well, I -might- but it would
    be a waste of effort.
    > Well, that would be silly, unless you boot from the scsi disk. If you
    > do that, then ...
    Not at all. I normally boot from /dev/hda5. The size of the kernel is
    irrelevant unless one is trying to build a rescue diskette. Should I need
    a rescue boot I use the Slackware installation CD and boot xfs.i to a root
    prompt.
    > The point is that normal sized kernels are almost one third the size of
    > his.
    You were probably correct about the OP using /usr/src/linux/vmlinux
    instead of /usr/src/linux/arch/i386/boot/bzImage as his kernel. OP likely
    does not even know where bzImage is located after a kernel build.

    Dave Uhring Guest

  7. #7

    Default Re: kernel is always too big....

    Dave Uhring <daveuhring> wrote:
    > On Fri, 18 Jul 2003 22:15:39 +0200, Peter T. Breuer wrote:
    >> T <dejabluefiremail.de> wrote:
    >>> my kernel is between 2.2 MB and 2.8 MB big.
    >>
    >> Well, that's about 3 times too big.
    > Lot smaller than my vmlinuz:
    > -rwxr-xr-x 1 root root 3921955 Jun 19 21:08 vmlinux
    > and only twice the size of a kernel built to support XFS and no modules
    > required:
    > -rw-r--r-- 1 root root 1459916 Jun 19 21:08 vmlinuz-2.4.21-xfs
    That's big, I have tons of stuff built in, could be easily stripped down more,
    but then I don't change the config that much.

    -rw-r--r-- 1 root root 999407 Nov 7 2002 /boot/vmlinuz-2.4.19
    -rw-r--r-- 1 root root 1019766 Dec 1 2002 /boot/vmlinuz-2.4.20
    -rw-r--r-- 1 root root 1024084 Feb 14 22:07 /boot/vmlinuz-2.4.20mh
    -rw-r--r-- 1 root root 1024188 Mar 20 18:46 /boot/vmlinuz-2.4.20mh-pt
    -rw-r--r-- 1 root root 1038353 Jun 14 09:57 /boot/vmlinuz-2.4.21

    One doesn't get any remarkable uptime this way, but then I had one CPU melt
    down this year.;)

    --
    Michael Heiming

    Remove +SIGNS and www. if you expect an answer, sorry for
    inconvenience, but I get tons of SPAM
    Michael Heiming Guest

  8. #8

    Default Re: kernel is always too big....

    On Sat, 19 Jul 2003 00:16:32 +0200, Michael Heiming wrote:
    >
    >> and only twice the size of a kernel built to support XFS and no modules
    >> required:
    >
    >> -rw-r--r-- 1 root root 1459916 Jun 19 21:08 vmlinuz-2.4.21-xfs
    >
    > That's big, I have tons of stuff built in, could be easily stripped down more,
    > but then I don't change the config that much.
    >
    > -rw-r--r-- 1 root root 999407 Nov 7 2002 /boot/vmlinuz-2.4.19
    > -rw-r--r-- 1 root root 1019766 Dec 1 2002 /boot/vmlinuz-2.4.20
    > -rw-r--r-- 1 root root 1024084 Feb 14 22:07 /boot/vmlinuz-2.4.20mh
    > -rw-r--r-- 1 root root 1024188 Mar 20 18:46 /boot/vmlinuz-2.4.20mh-pt
    > -rw-r--r-- 1 root root 1038353 Jun 14 09:57 /boot/vmlinuz-2.4.21
    >
    > One doesn't get any remarkable uptime this way, but then I had one CPU melt
    > down this year.;)
    I saw one posting on comp.unix.solaris where the OP was running the
    108528-01 kernel and was bragging about his uptime. That kernel is the
    FCS kernel from Jan 2000 and the machine had never been rebooted. Current
    patch level is -22. Is uptime more important than keeping one's system
    updated? I don't think so.

    Even IBM seems to recommend periodic "maintenance downtimes", and at least
    one place I know of that happens each Sunday for a dual S-390
    installation.

    Much of the difference in size between our kernels is due to the XFS
    filesystem which I use and perhaps the SCSI drivers. The only modules
    which I load are those required for lm-sensors to work with gkrellm.

    If you had that working you might have seen your CPU temp rising ;-)

    Dave Uhring Guest

  9. #9

    Default Re: kernel is always too big....

    Dave Uhring <daveuhring> wrote:
    > On Sat, 19 Jul 2003 00:16:32 +0200, Michael Heiming wrote:
    >> -rw-r--r-- 1 root root 999407 Nov 7 2002 /boot/vmlinuz-2.4.19
    >> -rw-r--r-- 1 root root 1019766 Dec 1 2002 /boot/vmlinuz-2.4.20
    >> -rw-r--r-- 1 root root 1024084 Feb 14 22:07 /boot/vmlinuz-2.4.20mh
    >> -rw-r--r-- 1 root root 1024188 Mar 20 18:46 /boot/vmlinuz-2.4.20mh-pt
    >> -rw-r--r-- 1 root root 1038353 Jun 14 09:57 /boot/vmlinuz-2.4.21
    >>
    >> One doesn't get any remarkable uptime this way, but then I had one CPU melt
    >> down this year.;)
    > I saw one posting on comp.unix.solaris where the OP was running the
    > 108528-01 kernel and was bragging about his uptime. That kernel is the
    > FCS kernel from Jan 2000 and the machine had never been rebooted. Current
    > patch level is -22. Is uptime more important than keeping one's system
    > updated? I don't think so.
    There was a system with >1200 days uptime.;)

    Honestly, as you can see from my above list, there is a constant rebooting, cause
    of kernel updates. If you need availability you need a cluster anyway.
    > If you had that working you might have seen your CPU temp rising ;-)
    Had lm_sensors/i2c working on some of the above kernel, but just the
    time the CPU melt away I was just thinking about monitoring temperature,
    but I've been told that those older Athlons have a bug which will drain
    more voltage if the get overheated (fan failure), which melts them away
    even faster. Unsure if this leaves enough time to shutdown the box,
    doesn't sound like.

    BTW
    Keep an eye on ;)

    --
    Michael Heiming

    Remove +SIGNS and www. if you expect an answer, sorry for
    inconvenience, but I get tons of SPAM
    Michael Heiming Guest

  10. #10

    Default Re: kernel is always too big....

    On Sat, 19 Jul 2003 01:39:05 +0200, Michael Heiming wrote:
    > There was a system with >1200 days uptime.;)
    I wonder how many zombie trojans were installed on that one.
    > Honestly, as you can see from my above list, there is a constant rebooting, cause
    > of kernel updates. If you need availability you need a cluster anyway.
    Live Upgrade on Solaris 8 and 9 provides that capability on single machine
    systems. A bit of a PITA to implement, but possibly worth it. Better
    IMHO to simply insist on periodic scheduled downtime.
    > Had lm_sensors/i2c working on some of the above kernel, but just the
    > time the CPU melt away I was just thinking about monitoring temperature,
    We usually get bitten by procrastinating, don't we?
    > but I've been told that those older Athlons have a bug which will drain
    > more voltage if the get overheated (fan failure), which melts them away
    > even faster. Unsure if this leaves enough time to shutdown the box,
    > doesn't sound like.
    A failing fan will probably show up in the lm_sensors display on gkrellm.
    Mine is running at 6490 rpm right now with CPU core temp at 50.7 C. It
    -is- time for a system cleaning. That temp should be closer to 44 C at
    the current ambient of 25.3 C.

    But you are likely correct about early Athlons cooking themselves to
    death with inadequate cooling. One of the critical differences between
    PeeCees and servers like my AlphaServer is that the Alpha will shut down
    when the fan speed drops from a nominal value.

    In fact, I got that AlphaServer 4100 gratis because the previous sys
    admin was too dumb to diagnose and fix the problem.

    Dave Uhring Guest

  11. #11

    Default Re: kernel is always too big....

    Dave Uhring <daveuhring> wrote:
    > On Fri, 18 Jul 2003 23:52:47 +0200, Peter T. Breuer wrote:
    >> Well, that would be silly, unless you boot from the scsi disk. If you
    >> do that, then ...
    > Not at all. I normally boot from /dev/hda5. The size of the kernel is
    > irrelevant unless one is trying to build a rescue diskette. Should I need
    Well, it's not /irrelevant/, since its size is generated by the number
    of drivers built in, which in turn is dependent on the number of drivers
    compiled /out/. And the more drivers compiled out the easier to
    maintain and operate is the kernel. But yes, the size itself is not
    directly either a boon or a problem.
    > a rescue boot I use the Slackware installation CD and boot xfs.i to a root
    > prompt.
    >> The point is that normal sized kernels are almost one third the size of
    >> his.
    > You were probably correct about the OP using /usr/src/linux/vmlinux
    > instead of /usr/src/linux/arch/i386/boot/bzImage as his kernel. OP likely
    > does not even know where bzImage is located after a kernel build.
    Nor do I nowadays. I gotta take a look at 2.6pre.

    Peter

    Peter T. Breuer Guest

  12. #12

    Default Re: kernel is always too big....

    Dave Uhring <daveuhring> wrote:
    > On Sat, 19 Jul 2003 05:18:24 +0200, Peter T. Breuer wrote:
    >> compiled /out/. And the more drivers compiled out the easier to
    >> maintain and operate is the kernel. But yes, the size itself is not
    >> directly either a boon or a problem.
    > If you don't change your hardware, what is the maintainability problem?
    Fixing bugs in drivers. Trying different irq/io options, and others.
    >> Nor do I nowadays. I gotta take a look at 2.6pre.
    > I'll look at it when SGI's CVSUP server supplies the kernel. I have no
    > intention of moving off of XFS. Even my Dead Rat 9 system is on XFS.
    That's a point.

    Peter
    Peter T. Breuer Guest

  13. #13

    Default Re: kernel is always too big....

    On Sat, 19 Jul 2003 05:53:38 +0200, Peter T. Breuer wrote:
    > Dave Uhring <daveuhring> wrote:
    >> If you don't change your hardware, what is the maintainability problem?
    >
    > Fixing bugs in drivers. Trying different irq/io options, and others.
    If you are re-writing those drivers or are using someone else's patches
    for those drivers, yes. Otherwise, no; there is no point whatever in
    relying on modutils which may be full of bugs, and those have had an
    infamous history.

    If you have had the good sense to use supported hardware in the first
    place ....

    Dave Uhring Guest

  14. #14

    Default Re: kernel is always too big....

    Dave Uhring <daveuhring> wrote:
    > On Sat, 19 Jul 2003 06:51:47 +0200, Peter T. Breuer wrote:
    >> Nowadays I'm always changing my xfs.o, for example!
    > Seems pretty stable here, although I keep that in the kernel. I suppose
    > you are providing your changes to SGI?
    I meant I follow cvs. They fix bugs faster than I find any. It's too
    hard to locate a bug in a strange fs code even if you spot the symptom
    and get a repeatable test for it. Well .. almost.
    >>> relying on modutils which may be full of bugs, and those have had an
    >>
    >> ?? Modutils has no interesting bugs. Never has had, as far as I know.
    > [url]http://www.ciac.org/ciac/bulletins/l-020.shtml[/url]
    As far as I recall, that was an error reporting bug - echo called
    under sh from the kernel would have metachars interpreted. I thought
    it was a funny. Anyway, it was two years ago or so?
    > [url]http://www.securityfocus.com/bid/1936/solution/[/url]
    Same, no?
    > [url]http://www.linuxsecurity.com/advisories/redhat_advisory-1848.html[/url]
    That appears to be a CIPE bug, not modutils.
    > There are some more if you wish to re-confirm that.
    Well, that was ONE bug. I recall two others, vaguely (link trick, and
    recursive modprobe). I'm not going to break sweat over it. They aren't
    indications of an endemic problem. kmod was intended to be simpler than
    kerneld too, precisely so that all bugs would hencefirth be obvious!
    >> Your sense of "infamous" seems equal to my sense of "completely solid"!
    > No, my sense of 'infamous' has to do with root holes.
    I'm not worried - if anyone finds a hole in modutils, it will be fixed
    within 10 minutes of publication. It's that basic! Why should I worry
    about it in that case? That would be like worrying in case anybody
    finds out that air is deadly to human life under some cirstances.
    >> There is no such thing. Some hardware has drivers - that doesn't mean
    >> that either the driver or the hardware is perfect, and bugs in both are
    >> discovered with high frequency. And then there's perfective
    >> maintenance. And there's adaptive maintenance (the environment changes
    >> to expose new flaws ..). I simply have to check many different versions
    >> of the same driver to locate the moment at which a behavior change
    >> happened.
    > Agreed, nothing will ever be perfect. The drivers in 2.4.21-xfs are
    > adequate for desktop use. Use Intel NICs (82557,82558) and you do not
    Oh, I agree, I do.
    > have to play games with 3Com's chip changes. When 3c905d becomes
    > available you will have the pleasure of fixing code again. Should I
    > repeat my comments about using supported hardware?
    3com have hysterically always supported linux and communicated with
    linux people. It's just that they change their chips like nobody's
    business and have their own bugs that they don't know about. It's all
    perfectly innocent.
    > If you are considering the use of any version of Linux as an NFS server
    > then you might consider a rewrite of the kernel. Linux NFS just does not
    > play well with UNIX and BSD clients, although it works well enough with
    > Linux clients.
    Well. sure. The packet ordering thing. But NFS is doing well here and
    has for going on ten years now.

    Peter
    Peter T. Breuer Guest

  15. #15

    Default Re: kernel is always too big....

    Dave Uhring <daveuhring> wrote:
    > On Sat, 19 Jul 2003 01:39:05 +0200, Michael Heiming wrote:
    >> There was a system with >1200 days uptime.;)
    > I wonder how many zombie trojans were installed on that one.
    Probably none, it was running Tru64 4.0D inside a secure network.
    ....
    > We usually get bitten by procrastinating, don't we?
    ;)
    ....
    > But you are likely correct about early Athlons cooking themselves to
    > death with inadequate cooling. One of the critical differences between
    > PeeCees and servers like my AlphaServer is that the Alpha will shut down
    > when the fan speed drops from a nominal value.
    Hard to compare some cheapo AMD CPU with a dozens of times more expensive
    $$ Alpha CPU, where you have at least RMC console to check for fans/temp.
    > In fact, I got that AlphaServer 4100 gratis because the previous sys
    > admin was too dumb to diagnose and fix the problem.
    Nice little box, hope it doesn't have those notorious falling HSZ controllers.
    Even if the are configured for dual redundancy and the configtool 'hszterm'
    is nice.;)

    --
    Michael Heiming

    Remove +SIGNS and www. if you expect an answer, sorry for
    inconvenience, but I get tons of SPAM
    Michael Heiming Guest

  16. #16

    Default Re: kernel is always too big....

    On Sat, 19 Jul 2003 09:15:38 +0200, Peter T. Breuer wrote:
    > I meant I follow cvs. They fix bugs faster than I find any. It's too
    > hard to locate a bug in a strange fs code even if you spot the symptom
    > and get a repeatable test for it. Well .. almost.
    Despite the barbs shot against XFS by that fellow from gentoo, I have
    never had a problem with XFS. But I use Linux on my desktop PeeCee and
    that probably obviates some of the problems of XFS. My servers run
    Solaris and OpenBSD. In fact, the machine from which this article arises
    is a Sun Ultra 1 running Solaris 9.
    > Well, that was ONE bug. I recall two others, vaguely (link trick, and
    > recursive modprobe). I'm not going to break sweat over it.
    So your statement "?? Modutils has no interesting bugs. Never has had,
    as far as I know." requires correction?

    The utilities are probably stable at this point. But the use of -any-
    otherwise unrequired utility carries risk with it.
    > I'm not worried - if anyone finds a hole in modutils, it will be fixed
    > within 10 minutes of publication. It's that basic! Why should I worry
    > about it in that case? That would be like worrying in case anybody
    > finds out that air is deadly to human life under some cirstances.
    Air is indeed deadly to human life for some people - those who dive in
    deep waters and return too swiftly to the surface.
    > 3com have hysterically always supported linux and communicated with
    > linux people. It's just that they change their chips like nobody's
    > business and have their own bugs that they don't know about. It's all
    > perfectly innocent.
    Naming a NIC which uses a different architecture with the same
    nomenclature as the previous generation is not innocent. It is mindful of
    the behavior of LinkSys with their LNE-100TX series of 4 separate chips
    and god_only_knows how many different chips sold by SMC.

    Use supported hardware and forget about having to modprobe some
    experimental module. You might enjoy fixing such things but most people
    simply do not have that capabilty.

    Do you think the OP now knows where to find bzImage?

    Dave Uhring Guest

  17. #17

    Default Re: kernel is always too big....

    Dave Uhring <daveuhring> wrote:
    > On Sat, 19 Jul 2003 10:25:41 +0200, Michael Heiming wrote:
    ....
    > Possibly. But is there such a thing as a "secure network"? 4.0D had its
    In this case, yes. Anyway, I have replaced the system with a Linux server.;)
    > share of root holes and there were a bunch of patches for it to fix most
    > of them, and a 1200 day uptime meant that those patches had not been
    > applied.
    The odd thing about 'dupatch'...
    > It has been a while since I booted the machine but it does not have HSZ.
    > The system is entirely stable when running. It just eats more kilowatts
    > than I can afford at the present.
    I can imagine, can't remember how much the power supplies eat. On a "wildfire"
    power cabinets use >4 kW.
    ;))

    --
    Michael Heiming

    Remove +SIGNS and www. if you expect an answer, sorry for
    inconvenience, but I get tons of SPAM
    Michael Heiming Guest

  18. #18

    Default Re: kernel is always too big....

    On Sat, 19 Jul 2003 12:07:50 +0200, Michael Heiming wrote:
    > In this case, yes. Anyway, I have replaced the system with a Linux
    > server.;)
    Hmmmm. I tried using Linux as a server but its NFS implementation does
    not follow Sun's standards. Both FreeBSD and OpenBSD worked better for
    that, and after running a trivial speed benchmark I found that Solaris x86
    worked even better.

    Linux works quite well as a client, and better than those other OS due to
    the availability of apps.
    > The odd thing about 'dupatch'...
    Is that if you apply the patches available from HPQ in chronological order
    some of the patches will not apply. Then, running dupatch on the newer
    patches will not work either since the earlier patches were not installed.
    A fancy tap dance is required to get the system patched.
    > I can imagine, can't remember how much the power supplies eat. On a "wildfire"
    > power cabinets use >4 kW.
    > ;))
    The AS 4100 is not quite that hungry. It is specced at a draw of 8 amps
    on a 120VAC line, or a bit under 1 kW. But that still translates to over
    $50USD/month if the machine is run 24/7.

    Dave Uhring Guest

  19. #19

    Default Re: kernel is always too big....

    Dave Uhring <daveuhring> wrote:
    > On Sat, 19 Jul 2003 12:07:50 +0200, Michael Heiming wrote:
    >> In this case, yes. Anyway, I have replaced the system with a Linux
    >> server.;)
    > Hmmmm. I tried using Linux as a server but its NFS implementation does
    > not follow Sun's standards. Both FreeBSD and OpenBSD worked better for
    > that, and after running a trivial speed benchmark I found that Solaris x86
    > worked even better.
    Astonishing, I'm running a few Linux system as NIS/NFS server with
    different clients (Tru64/HP-UX/Solaris/Linux), works like a charm,
    even if you need to set some obscure NFS options, according to the
    Linux NFS HOWTO.

    --
    Michael Heiming

    Remove +SIGNS and www. if you expect an answer, sorry for
    inconvenience, but I get tons of SPAM
    Michael Heiming Guest

  20. #20

    Default Re: kernel is always too big....

    Dave Uhring <daveuhring> wrote:
    ....
    > There was a short discussion of the Linux non-compliance with NFS on
    > [email]freebsd-stablefreebsd.org[/email] a couple of years ago. I have not been able to
    > locate the particular message, but it was a quite detailed description of
    > how Linux fails to comply with that open standard.
    This has probably changed in the last years, as mentioned it works (for me)
    like a charm.

    ....
    > If you are interested in doing a comparison Solaris for Intel is available
    > without a license fee for uni-processor systems. The download version has
    > a fee of $20 USD to offset the bandwidth cost.
    No thanks, Solaris x86 is dog slow and the hw support s. Unless you have
    some app that will only run on Solaris/Sparc(64bit), I'd prefer Linux any-day.
    ;)

    --
    Michael Heiming

    Remove +SIGNS and www. if you expect an answer, sorry for
    inconvenience, but I get tons of SPAM
    Michael Heiming Guest

Page 1 of 2 12 LastLast

Similar Threads

  1. kernel-source versus kernel-patch
    By Ismael Valladolid Torres in forum Debian
    Replies: 1
    Last Post: July 14th, 06:20 PM
  2. kernel 2.2.x or 2.4.x ?
    By Nicos Gollan in forum Debian
    Replies: 3
    Last Post: July 7th, 07:30 PM
  3. Replies: 15
    Last Post: July 3rd, 05:20 AM
  4. Kernel 2.4.20
    By Abrasive in forum Debian
    Replies: 2
    Last Post: June 30th, 01:50 PM
  5. Kernel 2.5.44
    By Nathan Poznick in forum Debian
    Replies: 3
    Last Post: June 30th, 02:30 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139