Re: [OT] Re: Snowhite and the Seven Dwarfs - The REAL story!
Or even better.. Rik? Are you using Microsoft again? Now we get em in Spanish too.. Even Virus's sound better in Spanish.. Or is that Portugese? (Personally, I block em at the mailer, to protect those poor unfortunates that haven't switched to Linux Yet) Content-Type: application/octet-stream; name="enano porno.exe" ==> virus-20010614-12825 <== Received: (qmail 11723 invoked by uid 1004); 14 Jun 2001 23:28:19 - Received: from dl-tnt2-c8b06e1e.rio.terra.com.br (HELO paulo) (200.176.110.30) by mail.wizard.ca with SMTP; 14 Jun 2001 23:28:19 - From: Hahaha <[EMAIL PROTECTED]> Subject: Branca de Neve pornô! MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--VE56J8TYRO9ABG1INC9EB8HU3" X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) On 15 Jun 2001 17:02:05 -0700, J Sloan wrote: > Tobias Ringstrom wrote: > > > Ah... the joy of reading mail using non-MS software, on a non-MS OS... > > > > Hahaha, indeed! > > Indeed, since: > > Jun 15 15:39:03 mirai sendmail[21499]: f5FMd2t21499: > from=<[EMAIL PROTECTED]>, size=33547, class=-60, nrcpts=1, > msgid=<[EMAIL PROTECTED]>, bodytype=7BIT, proto=ESMTP, daemon=MTA, > relay=freeside.toyota.com [63.87.74.7] > Jun 15 15:39:03 mirai scanmails[21501]: execution started > Jun 15 15:39:04 mirai scanmails[21501]: FOUND VIRUS IN MAIL from > [EMAIL PROTECTED] to jjs > > cu > > jjs > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > -- "Catch the Magic of Linux..." Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security WizardInternet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604)589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Snowhite and the Seven Dwarfs - The REAL story!
Or even better.. Rik? Are you using Microsoft again? Now we get em in Spanish too.. Even Virus's sound better in Spanish.. Or is that Portugese? (Personally, I block em at the mailer, to protect those poor unfortunates that haven't switched to Linux Yet) Content-Type: application/octet-stream; name=enano porno.exe == virus-20010614-12825 == Received: (qmail 11723 invoked by uid 1004); 14 Jun 2001 23:28:19 - Received: from dl-tnt2-c8b06e1e.rio.terra.com.br (HELO paulo) (200.176.110.30) by mail.wizard.ca with SMTP; 14 Jun 2001 23:28:19 - From: Hahaha [EMAIL PROTECTED] Subject: Branca de Neve pornô! MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=--VE56J8TYRO9ABG1INC9EB8HU3 X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) On 15 Jun 2001 17:02:05 -0700, J Sloan wrote: Tobias Ringstrom wrote: Ah... the joy of reading mail using non-MS software, on a non-MS OS... Hahaha, indeed! Indeed, since: Jun 15 15:39:03 mirai sendmail[21499]: f5FMd2t21499: from=[EMAIL PROTECTED], size=33547, class=-60, nrcpts=1, msgid=[EMAIL PROTECTED], bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=freeside.toyota.com [63.87.74.7] Jun 15 15:39:03 mirai scanmails[21501]: execution started Jun 15 15:39:04 mirai scanmails[21501]: FOUND VIRUS IN MAIL from [EMAIL PROTECTED] to jjs cu jjs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Catch the Magic of Linux... Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security WizardInternet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604)589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
This seems to be drifting into that old argument(s) of a forked kernel.. And of course here I am adding to the flotsams..and threadsomes 2.5 for Pentium Plus generation. <2.4 For older hardware.. Ducking the inevitable flames, I think for the most part, there might be justification for some forking.. (read obsolesence) Anyone with a <486 probably shudders at the space and time requirements of compiling modern kernels.. All they need is the older kernels.. The older boxes don't support the new hardware anyways.. But then there is always someone who will find a way to marry a new PCI or USB bus to an older CPU, and it is nice that 'one kernel to bind them' philosophy of linux.. But in this age of 'disposability' more and more people just accept they have to buy new hardware every 3-5 years.. For those that want to maintain Linux on that, so be it.. Maybe we need more Alan Cox's, and then we could have sperate kernel trees, Linus's which is the mother.. (HI MOM!) and the pre-pentium tree, the post-pentium tree, the embedded tree etc.. But in reality, with all the people contributing now to one tree, there is still more work to be done.. Who wants to split those resources? But it is a legitimate argument... In reality, hardware needs drive kernel upgrades.. and of course some security issues.. Those who have older hardware aren't interested in upgrading the kernel, why should they.. it is rock solid as it is.. And newer machines don't need support for the older hardware.. If you want to stay bleading edge kernel wise, usually you stay bleeding edge hardware wise.. But it is nice the we now can apply the power of iptables to older 486 firewalls.. BUT as much as it might be cleaner, and a little less headaches to drop all the fluff that doesn't usually get used, is it worth dropping it when all newer hardware doesn't care about a little bloat.. *cough* I can't believe I just supported bloat.. Okay, me personally, I wouldn't mind seeing tiny litle kernels and tiny little code trees, makes me feel more effecient, and I don't get blurry eyes from grepping so much code.. (Personally sometimes I think all this new power is wasted in PC's is wasted, but I have to admit.. these 10 second compiles vs the old 28 hour ones are nice) On 14 Jun 2001 02:13:29 +0100, Claudio Martins wrote: > On Thursday 14 June 2001 01:44, Daniel wrote: > > > -- If someone really needs support for this junk, they will always have the > > option of using the 2.0.x, 2.2.x or 2.4.x series. > > > > You mean you want 2.5+ series to just stop supporting all older hardware? -- "Catch the Magic of Linux..." -------- Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security WizardInternet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604)589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
This seems to be drifting into that old argument(s) of a forked kernel.. And of course here I am adding to the flotsams..and threadsomes 2.5 for Pentium Plus generation. 2.4 For older hardware.. Ducking the inevitable flames, I think for the most part, there might be justification for some forking.. (read obsolesence) Anyone with a 486 probably shudders at the space and time requirements of compiling modern kernels.. All they need is the older kernels.. The older boxes don't support the new hardware anyways.. But then there is always someone who will find a way to marry a new PCI or USB bus to an older CPU, and it is nice that 'one kernel to bind them' philosophy of linux.. But in this age of 'disposability' more and more people just accept they have to buy new hardware every 3-5 years.. For those that want to maintain Linux on that, so be it.. Maybe we need more Alan Cox's, and then we could have sperate kernel trees, Linus's which is the mother.. (HI MOM!) and the pre-pentium tree, the post-pentium tree, the embedded tree etc.. But in reality, with all the people contributing now to one tree, there is still more work to be done.. Who wants to split those resources? But it is a legitimate argument... In reality, hardware needs drive kernel upgrades.. and of course some security issues.. Those who have older hardware aren't interested in upgrading the kernel, why should they.. it is rock solid as it is.. And newer machines don't need support for the older hardware.. If you want to stay bleading edge kernel wise, usually you stay bleeding edge hardware wise.. But it is nice the we now can apply the power of iptables to older 486 firewalls.. BUT as much as it might be cleaner, and a little less headaches to drop all the fluff that doesn't usually get used, is it worth dropping it when all newer hardware doesn't care about a little bloat.. *cough* I can't believe I just supported bloat.. Okay, me personally, I wouldn't mind seeing tiny litle kernels and tiny little code trees, makes me feel more effecient, and I don't get blurry eyes from grepping so much code.. (Personally sometimes I think all this new power is wasted in PC's is wasted, but I have to admit.. these 10 second compiles vs the old 28 hour ones are nice) On 14 Jun 2001 02:13:29 +0100, Claudio Martins wrote: On Thursday 14 June 2001 01:44, Daniel wrote: -- If someone really needs support for this junk, they will always have the option of using the 2.0.x, 2.2.x or 2.4.x series. You mean you want 2.5+ series to just stop supporting all older hardware? -- Catch the Magic of Linux... Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security WizardInternet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604)589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Just FYI...
H.. In principle this sounds good, but... This doesn't seem to be in best interest.. Taking it to the extreme, noone should code the linux kernel for buggy bios's, cards etc anymore either.. We should all tell em to upgrade their hardware? Almost every software application has made allowances for buggy or non-compliance systems. We should encourage their disuse, but should we play god? I still vote against anything that prevents someone from contributing to the linux kernel, the movement, and since these mailing lists are the 'official' way of contributing, aren't we going to far? Our way or the highway sentiment seems more in keeping with corporate attitudes than with the 'open' attitudes that the open source movement fosters. Just My Humble Opinion... On 21 May 2001 18:04:01 -0700, David S. Miller wrote: > > vger.kernel.org is now ECN enabled. > > Later, > David S. Miller > [EMAIL PROTECTED] > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- "Catch the Magic of Linux..." -------- Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security WizardInternet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604)589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Just FYI...
H.. In principle this sounds good, but... This doesn't seem to be in best interest.. Taking it to the extreme, noone should code the linux kernel for buggy bios's, cards etc anymore either.. We should all tell em to upgrade their hardware? Almost every software application has made allowances for buggy or non-compliance systems. We should encourage their disuse, but should we play god? I still vote against anything that prevents someone from contributing to the linux kernel, the movement, and since these mailing lists are the 'official' way of contributing, aren't we going to far? Our way or the highway sentiment seems more in keeping with corporate attitudes than with the 'open' attitudes that the open source movement fosters. Just My Humble Opinion... On 21 May 2001 18:04:01 -0700, David S. Miller wrote: vger.kernel.org is now ECN enabled. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Catch the Magic of Linux... Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security WizardInternet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604)589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OT] Re: goodbye
Uh... use their ISP relay service anyway??? I take my laptop all over, to lot's of my clients locations, and if I could relay through their servers, then I had better give them some good advice.. Some places I just pick an available IP and it might not be in the allowed relay list. And this happens when I am in M$ or Linux.. And sometimes, I even go to locations where they can't tell me their ISP's SMTP mailer.. Not to mention, I shouln't have to reset my configuration for each location I happen to be at.. The point is, if it is a pain, then people will be less likely to contribute.. My point was that.. the LKML shouldn't make it tough for legimate posters.. And if someone's purpose is to spam the list, they can get around DULS easy enough.. On 08 Apr 2001 02:32:28 +0300, Matti Aarnio wrote: > On Tue, Apr 03, 2001 at 06:14:33PM -0700, Michael Peddemors wrote: > > This would be a shame, as he has been a valuable resource.. > > Why has the list become more restrictive? > The incentive behind the DUL is to force users not to post > straight out to the world, but to use their ISP's servers > for outbound email --- normal M$ users do that, after all. > Only spammers - and UNIX powerusers - want to post directly > to the world from dialups. And UNIX powerusers should know > better, and be able to use ISP relay service anyway. > -- "Catch the Magic of Linux..." -------- Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security WizardInternet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604)589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OT] Re: goodbye
Uh... use their ISP relay service anyway??? I take my laptop all over, to lot's of my clients locations, and if I could relay through their servers, then I had better give them some good advice.. Some places I just pick an available IP and it might not be in the allowed relay list. And this happens when I am in M$ or Linux.. And sometimes, I even go to locations where they can't tell me their ISP's SMTP mailer.. Not to mention, I shouln't have to reset my configuration for each location I happen to be at.. The point is, if it is a pain, then people will be less likely to contribute.. My point was that.. the LKML shouldn't make it tough for legimate posters.. And if someone's purpose is to spam the list, they can get around DULS easy enough.. On 08 Apr 2001 02:32:28 +0300, Matti Aarnio wrote: On Tue, Apr 03, 2001 at 06:14:33PM -0700, Michael Peddemors wrote: This would be a shame, as he has been a valuable resource.. Why has the list become more restrictive? The incentive behind the DUL is to force users not to post straight out to the world, but to use their ISP's servers for outbound email --- normal M$ users do that, after all. Only spammers - and UNIX powerusers - want to post directly to the world from dialups. And UNIX powerusers should know better, and be able to use ISP relay service anyway. -- "Catch the Magic of Linux..." -------- Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security WizardInternet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604)589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: a quest for a better scheduler
Missing an important one, our VPN's routinely run on 16 MG Ram, no HD or swap.. Loaded from an initrd on a floppy.. Don't we need to test on minimalistic machines as well :) > So the server hardware configurations have evolved to look like > the following. > > 1 way, 512 MB, 2 IDE > 2 way, 1 GB, 10 SCSI (1 SCSI channel) > 4 way, 4 GB, 20 SCSI (2 channels) > 8 way, 8 GB, 40 SCSI (4 channels) maybe Fibre Channel (FC) >16 way, 16 GB, 80 FC (8 channels) > -- "Catch the Magic of Linux..." -------- Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security WizardInternet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604)589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: a quest for a better scheduler
Missing an important one, our VPN's routinely run on 16 MG Ram, no HD or swap.. Loaded from an initrd on a floppy.. Don't we need to test on minimalistic machines as well :) So the server hardware configurations have evolved to look like the following. 1 way, 512 MB, 2 IDE 2 way, 1 GB, 10 SCSI (1 SCSI channel) 4 way, 4 GB, 20 SCSI (2 channels) 8 way, 8 GB, 40 SCSI (4 channels) maybe Fibre Channel (FC) 16 way, 16 GB, 80 FC (8 channels) -- "Catch the Magic of Linux..." -------- Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security WizardInternet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604)589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: goodbye
This would be a shame, as he has been a valuable resource.. Why has the list become more restrictive? I think that this is one list where we have to keep the ability to post from individuals separate from the need to make sure that their ISP or company is compliant to a set a of rules.. The LKML can't toe the strictest of lines, without loosing some possibly valuable contributors.. On 03 Apr 2001 18:01:42 -0300, Rik van Riel wrote: > Hi, > > this will be my last email to linux-kernel for a while since > davem and matti are using DUL on vger.kernel.org > > If you need to know something, don't count on me posting > anything here. For memory management things, please use > [EMAIL PROTECTED] instead. > > Rik > -- > Virtual memory is like a game you can't win; > However, without VM there's truly nothing to lose... > > http://www.surriel.com/ > http://www.conectiva.com/ http://distro.conectiva.com.br/ > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- "Catch the Magic of Linux..." Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security WizardInternet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604)589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: goodbye
This would be a shame, as he has been a valuable resource.. Why has the list become more restrictive? I think that this is one list where we have to keep the ability to post from individuals separate from the need to make sure that their ISP or company is compliant to a set a of rules.. The LKML can't toe the strictest of lines, without loosing some possibly valuable contributors.. On 03 Apr 2001 18:01:42 -0300, Rik van Riel wrote: Hi, this will be my last email to linux-kernel for a while since davem and matti are using DUL on vger.kernel.org If you need to know something, don't count on me posting anything here. For memory management things, please use [EMAIL PROTECTED] instead. Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- "Catch the Magic of Linux..." -------- Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security WizardInternet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604)589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOM killer???
Looking over the last few weeks of postings, there are just WAY to many conflicting ways that people want the OOM to work.. Although an incredible amount of good work has gone into this, people are definetely not happy about the benifits of OOM ... About 10 different approaches are being made to change the rule based systems pertaining to WHEN the OOM will fire, but in the end, still not everyone will be happy.. The old way of having a machien crash when you asked too much of it seemed acceptable.. People then either chose to run the mem hog, and upgrade their boxes, or they stopped running the memhog. Maybe its time to hear from on high whether OOM capability outweighs the problems that seem to be associated with it? Either that or we should be able to allow the end user/and the distros to decide what gets killed by OOM. Some people might like to just say to heck with it, and not let anything get killed, while others may just want to protect certain things.. Speaking completely where I don't belong, and don't know enough about.. Just a thought, can we come up with a new form of execute bit that would define whether OOM should affect the process? Then the app can be made to be killable if not as root etc... As well as being applied simply at a per application basis, because we KNOW that not all applications will ever be completely system friendly.. There will always be useful programs that might not fit into a OOM model well. Linus has been notably quite of late about this issue, given the amount of contention on this issue.. On 29 Mar 2001 07:41:44 -0800, David Konerding wrote: > Now, if you're going to implement OOM, when it is absolutely necessary, at the very > least, move the policy implementation out of the kernel. One of the general > philosophies of Linux has been to move policy out of the kernel. In this case, you'd > just have a root owned process with locked pages that can't be pre-empted, which > implemented the policy. You'll never come up with an OOM policy that will fit > everybody's needs unless it can be tuned for particular system's usage, and it's > going to be far easier to come up with that policy if it's not in the kernel. -- "Catch the Magic of Linux..." -------- Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security WizardInternet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604)589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOM killer???
Looking over the last few weeks of postings, there are just WAY to many conflicting ways that people want the OOM to work.. Although an incredible amount of good work has gone into this, people are definetely not happy about the benifits of OOM ... About 10 different approaches are being made to change the rule based systems pertaining to WHEN the OOM will fire, but in the end, still not everyone will be happy.. The old way of having a machien crash when you asked too much of it seemed acceptable.. People then either chose to run the mem hog, and upgrade their boxes, or they stopped running the memhog. Maybe its time to hear from on high whether OOM capability outweighs the problems that seem to be associated with it? Either that or we should be able to allow the end user/and the distros to decide what gets killed by OOM. Some people might like to just say to heck with it, and not let anything get killed, while others may just want to protect certain things.. Speaking completely where I don't belong, and don't know enough about.. Just a thought, can we come up with a new form of execute bit that would define whether OOM should affect the process? Then the app can be made to be killable if not as root etc... As well as being applied simply at a per application basis, because we KNOW that not all applications will ever be completely system friendly.. There will always be useful programs that might not fit into a OOM model well. Linus has been notably quite of late about this issue, given the amount of contention on this issue.. On 29 Mar 2001 07:41:44 -0800, David Konerding wrote: Now, if you're going to implement OOM, when it is absolutely necessary, at the very least, move the policy implementation out of the kernel. One of the general philosophies of Linux has been to move policy out of the kernel. In this case, you'd just have a root owned process with locked pages that can't be pre-empted, which implemented the policy. You'll never come up with an OOM policy that will fit everybody's needs unless it can be tuned for particular system's usage, and it's going to be far easier to come up with that policy if it's not in the kernel. -- "Catch the Magic of Linux..." -------- Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security WizardInternet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604)589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM handling
Uh... and aside from init, mission critical stuff... crond should never get killed, it runs mission critical cleanup tasks.. If crond dies, might as well make the machine die in a lot of cases.. I hate to miss my nightly database exports... Getting to look more and more like we need some way to configure certain tasks at the admin level to never die.. -- "Catch the Magic of Linux..." -------- Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security WizardInternet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604)589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM handling
Uh... and aside from init, mission critical stuff... crond should never get killed, it runs mission critical cleanup tasks.. If crond dies, might as well make the machine die in a lot of cases.. I hate to miss my nightly database exports... Getting to look more and more like we need some way to configure certain tasks at the admin level to never die.. -- "Catch the Magic of Linux..." -------- Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security WizardInternet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604)589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent OOM from killing init
Here, Here.. killing qmail on a server who's sole task is running mail doesn't seem to make much sense either.. > > Clearly, Linux cannot be reliable if any process can be killed > > at any moment. I am not happy at all with my recent experiences. > > Really the whole oom_kill process seems bass-ackwards to me. I can't in my mind > logically justify annihilating large-VM processes that have been running for > days or weeks instead of just returning ENOMEM to a process that just started > up. > > We run Oracle on a development box here, and it's always the first to get the > axe (non-root process using 70-80 MB VM). Whenever someone's testing decides to > run away with memory, I usually spend the rest of the day getting intimate with > the backup files, since SIGKILLing random Oracle processes, as you might have > guessed, has a tendency to rape the entire database. -- "Catch the Magic of Linux..." -------- Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security WizardInternet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604)589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent OOM from killing init
Here, Here.. killing qmail on a server who's sole task is running mail doesn't seem to make much sense either.. Clearly, Linux cannot be reliable if any process can be killed at any moment. I am not happy at all with my recent experiences. Really the whole oom_kill process seems bass-ackwards to me. I can't in my mind logically justify annihilating large-VM processes that have been running for days or weeks instead of just returning ENOMEM to a process that just started up. We run Oracle on a development box here, and it's always the first to get the axe (non-root process using 70-80 MB VM). Whenever someone's testing decides to run away with memory, I usually spend the rest of the day getting intimate with the backup files, since SIGKILLing random Oracle processes, as you might have guessed, has a tendency to rape the entire database. -- "Catch the Magic of Linux..." -------- Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security WizardInternet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604)589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATE] zerocopy.. While working on ip.h stuff
On Mon, 26 Feb 2001, Benjamin C.R. LaHaise wrote: > On Mon, 26 Feb 2001, David S. Miller wrote: > > At gigapacket rates, it becomes an issue. This guy is talking about > > tinkering with new IP _options_, not just the header. So even if the > > IP header itself fits totally in a cache line, the options afterwardsd > > likely will not and thus require another cache miss. Yes, I expect to use the whole of the allowed size :) So instead of the more common IP Header length of 20 bytes, I will be using 25-60 bytes for a header, (But so does source routing) and the router RFC says that we should handle it... Now, of course, you have raised the question of whether that would be handled effeciently with the current kernel code.. > Hmmm, one way around this is to have the packet queue store things in > in a linear array of pointers to data areas, then process things in > bursts, ie: > > - find packet data areas for queued packets > - walk list doing prefetches of ip header and options > - then actually do the packet processing (save output for later) > > That will require a number of new hooks for pipelining operations, though. > Just a thought. > > -ben -- "Catch the magic of Linux...." ---- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATE] zerocopy.. While working on ip.h stuff
On Mon, 26 Feb 2001, David S. Miller wrote: > > Also, I was looking into some RFC 1812 stuff. (Thanks for nothing Dave > > :) and was looking at 4.2.2.6 where it mentions that a router MUST > > implement the End of Option List option.. Havent' figured out where > > that is implememented yet.. > > egrep "IPOPT_END" net/ipv4/ip_options.c > > You just aren't looking hard enough. Was looking for IPOPT_EOL :) Forgot about it's reference.. -- "Catch the magic of Linux" -------- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATE] zerocopy.. While working on ip.h stuff
On Mon, 26 Feb 2001, Craig Milo Rogers wrote: > > > I have a whole 40 bytes (+/-) to share... Now although I don't see > > > anything explicitly prohibiting the use of unused IP Header option .. > > > in between.. Has anyone seen any RFC that explicitly says I MUST NOT? > > > >Not to my knowledge. Routers already change the time to live field, > >so I see no reason why they can't do smart things with special IP > >options either (besides efficiency concerns :-). I know they 'rewrite/extend' existing options, but have never seen a case where a router adds an option to a packet beyond those based on what the original sender set.. > I've forgotten how the Stream ID option was implemented, but I > won't be surprised if a router inserted it on the fly (but it was > probably inserted by end systems). On the other hand, there was also Hmm, have to look at a little history.. > a competing philosophy that said that the IP checksum must be > recomputed incrementally at routers to catch hardware problems in the > routers, and an incremental recomputation when changing the size of > the header would be more work. ah.. we do recalculate IP Checksums now.. when we update any of the timestamp rr options etc.. > The one thing I would worry about is unleashing mutant IP > packets upon the world at large. I hope the proposed experiments have > a very good firewall. It would be very nice to attempt to acquire an > officially blessed IP option number for such experiments before > unleashing these packets upon an unprepared world. > > Craig Milo Rogers Ah, we better have a good firewall No, if this goes past concept phase, we will try for de official bless. -- "Catch the magic of Linux" Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATE] zerocopy.. While working on ip.h stuff
While doing some work on some ip options stuff, I have noticed a bunchof unused entries in linux/include/linux/ip.h A few things.. why is ip.h not part of the linux/include/net rather than linux/include/linux hierachy? Defined items that are not used anywhere in the source.. Can any of them be deleted now? Also, I was looking into some RFC 1812 stuff. (Thanks for nothing Dave :) and was looking at 4.2.2.6 where it mentions that a router MUST implement the End of Option List option.. Havent' figured out where that is implememented yet.. Also was trying to figure out some things. I want to create a new ip_option for use in some DOS protection experiments. I have a whole 40 bytes (+/-) to share... Now although I don't see anything explicitly prohibiting the use of unused IP Header option space, I know that it really was designed for use by the sending parties, and not routers in between.. Has anyone seen any RFC that explicitly says I MUST NOT? IPTOS_PREC_NETCONTROL IPTOS_PREC_FLASHOVERRIDE IPTOS_PREC_FLASH IPTOS_PREC_IMMEDIATE IPTOS_PREC_PRIORITY IPTOS_PREC_ROUTINE IPOPT_RESERVED1 IPOPT_RESERVED2 IPOPT_OPTVAL IPOPT_OLEN IPOPT_MINOFF MAX_IPOPTLEN IPOPT_EOL > diff -urN linux/include/net/ip.h linux.fixed/include/net/ip.h ---- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATE] zerocopy.. While working on ip.h stuff
While doing some work on some ip options stuff, I have noticed a bunchof unused entries in linux/include/linux/ip.h A few things.. why is ip.h not part of the linux/include/net rather than linux/include/linux hierachy? Defined items that are not used anywhere in the source.. Can any of them be deleted now? see below Also, I was looking into some RFC 1812 stuff. (Thanks for nothing Dave :) and was looking at 4.2.2.6 where it mentions that a router MUST implement the End of Option List option.. Havent' figured out where that is implememented yet.. Also was trying to figure out some things. I want to create a new ip_option for use in some DOS protection experiments. I have a whole 40 bytes (+/-) to share... Now although I don't see anything explicitly prohibiting the use of unused IP Header option space, I know that it really was designed for use by the sending parties, and not routers in between.. Has anyone seen any RFC that explicitly says I MUST NOT? IPTOS_PREC_NETCONTROL IPTOS_PREC_FLASHOVERRIDE IPTOS_PREC_FLASH IPTOS_PREC_IMMEDIATE IPTOS_PREC_PRIORITY IPTOS_PREC_ROUTINE IPOPT_RESERVED1 IPOPT_RESERVED2 IPOPT_OPTVAL IPOPT_OLEN IPOPT_MINOFF MAX_IPOPTLEN IPOPT_EOL diff -urN linux/include/net/ip.h linux.fixed/include/net/ip.h Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATE] zerocopy.. While working on ip.h stuff
On Mon, 26 Feb 2001, Craig Milo Rogers wrote: I have a whole 40 bytes (+/-) to share... Now although I don't see anything explicitly prohibiting the use of unused IP Header option .. in between.. Has anyone seen any RFC that explicitly says I MUST NOT? Not to my knowledge. Routers already change the time to live field, so I see no reason why they can't do smart things with special IP options either (besides efficiency concerns :-). I know they 'rewrite/extend' existing options, but have never seen a case where a router adds an option to a packet beyond those based on what the original sender set.. I've forgotten how the Stream ID option was implemented, but I won't be surprised if a router inserted it on the fly (but it was probably inserted by end systems). On the other hand, there was also Hmm, have to look at a little history.. a competing philosophy that said that the IP checksum must be recomputed incrementally at routers to catch hardware problems in the routers, and an incremental recomputation when changing the size of the header would be more work. ah.. we do recalculate IP Checksums now.. when we update any of the timestamp rr options etc.. The one thing I would worry about is unleashing mutant IP packets upon the world at large. I hope the proposed experiments have a very good firewall. It would be very nice to attempt to acquire an officially blessed IP option number for such experiments before unleashing these packets upon an unprepared world. Craig Milo Rogers Ah, we better have a good firewall wink No, if this goes past concept phase, we will try for de official bless. -- "Catch the magic of Linux" -------- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATE] zerocopy.. While working on ip.h stuff
On Mon, 26 Feb 2001, David S. Miller wrote: Also, I was looking into some RFC 1812 stuff. (Thanks for nothing Dave :) and was looking at 4.2.2.6 where it mentions that a router MUST implement the End of Option List option.. Havent' figured out where that is implememented yet.. egrep "IPOPT_END" net/ipv4/ip_options.c You just aren't looking hard enough. Was looking for IPOPT_EOL :) Forgot about it's reference.. -- "Catch the magic of Linux" -------- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATE] zerocopy.. While working on ip.h stuff
On Mon, 26 Feb 2001, Benjamin C.R. LaHaise wrote: On Mon, 26 Feb 2001, David S. Miller wrote: At gigapacket rates, it becomes an issue. This guy is talking about tinkering with new IP _options_, not just the header. So even if the IP header itself fits totally in a cache line, the options afterwardsd likely will not and thus require another cache miss. Yes, I expect to use the whole of the allowed size :) So instead of the more common IP Header length of 20 bytes, I will be using 25-60 bytes for a header, (But so does source routing) and the router RFC says that we should handle it... Now, of course, you have raised the question of whether that would be handled effeciently with the current kernel code.. Hmmm, one way around this is to have the packet queue store things in in a linear array of pointers to data areas, then process things in bursts, ie: - find packet data areas for queued packets - walk list doing prefetches of ip header and options - then actually do the packet processing (save output for later) That will require a number of new hooks for pipelining operations, though. Just a thought. -ben -- "Catch the magic of Linux" -------- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 updates
On Fri, 26 Jan 2001, Svenning Soerensen wrote: Agreed, > Of course, the ideal solution would be to have just one instance of zlib > in the kernel, which the different parts could make use of. That would > require some cooperation with the kernel developers though. > > > Regards, > > > > Ferdinand O. Tempel > > Svenning -- -------- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 updates
On Fri, 26 Jan 2001, Svenning Soerensen wrote: Agreed, Of course, the ideal solution would be to have just one instance of zlib in the kernel, which the different parts could make use of. That would require some cooperation with the kernel developers though. Regards, Ferdinand O. Tempel Svenning -- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Is sendfile all that sexy?
The two things I change everytime are sendmail->qmail and wuftpd->proftpd But remember, security bugs are caught because more people use one vs the other.. Bugs in Proftpd weren't caught until more people started changing from wu-ftpd... Often, all it means when one product has more bugs than another, is that more people tried to find bugs in one than another... (Yes, a plug to get everyone to test 2.4 here) On Sun, 14 Jan 2001, Linus Torvalds wrote: > On Sun, 14 Jan 2001, Gerhard Mack wrote: > > PS I wish someone would explain to me why distros insist on using WU > > instead given it's horrid security record. > > Of course, you may be right on wuftpd. It obviously wasn't designed with > security in mind, other alternatives may be better. > > Linus -- -------- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Is sendfile all that sexy?
The two things I change everytime are sendmail-qmail and wuftpd-proftpd But remember, security bugs are caught because more people use one vs the other.. Bugs in Proftpd weren't caught until more people started changing from wu-ftpd... Often, all it means when one product has more bugs than another, is that more people tried to find bugs in one than another... (Yes, a plug to get everyone to test 2.4 here) On Sun, 14 Jan 2001, Linus Torvalds wrote: On Sun, 14 Jan 2001, Gerhard Mack wrote: PS I wish someone would explain to me why distros insist on using WU instead given it's horrid security record. Of course, you may be right on wuftpd. It obviously wasn't designed with security in mind, other alternatives may be better. Linus -- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: innd mmap bug in 2.4.0-test12
> Yeah, yeah, it's 7PM Christmas Eve over there, and you're in the middle of > your Christmas dinner. You might feel that it's unreasonable of me to ask > you to test out my latest crazy idea. > > How selfish of you. > > Get back there in front of the computer NOW. Christmas can wait. > > Linus "the Grinch" Torvalds I can just imagine Xmas at the Torvalds residence, with their annual tradition of having the kids scream... But dad, other kids have the lights strung around the trees, not the computer Linus, that's why they call them computer 'boxes'... didn't you know you are supposed to wait for 'boxing day' before climbing back in front of the screen?? -- -------- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: innd mmap bug in 2.4.0-test12
Yeah, yeah, it's 7PM Christmas Eve over there, and you're in the middle of your Christmas dinner. You might feel that it's unreasonable of me to ask you to test out my latest crazy idea. How selfish of you. Get back there in front of the computer NOW. Christmas can wait. Linus "the Grinch" Torvalds I can just imagine Xmas at the Torvalds residence, with their annual tradition of having the kids scream... But dad, other kids have the lights strung around the trees, not the computer Linus, that's why they call them computer 'boxes'... didn't you know you are supposed to wait for 'boxing day' before climbing back in front of the screen?? -- -------- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No more DoS
> Furthermore, it also cannot work because it makes retransmissions > of the SYN/ACK very non-workable. I suppose his TCP stack just hacks > around this by just waiting for the original client SYN to get > retransmitted or something like this. I question whether that can > even work reliably. Be interesting to see his response, but in truth, do we care if it gets retransmitted?? When it does, it does... > I think not holding onto any state for an incoming SYN is nothing but > a dream in any serious modern TCP implementation. It can be reduced, > but not eliminated. The former is what most modern stacks have done > to fight these problems. A dream, maybe but hey so were most things that we now take for granted.. Worth kicking around a bit tho... -------- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No more DoS
Not only is this a well written article, and clearer than most other documents (Even Mine :>) but he is dead on track with his basic concepts.. Exactly what I have been looking into over at our company. (Well, close enough) The concept of trusting a SYN packet, has to go.. we have to assume that it is false/bad, and only after receiving the ACK in reply to our SYN/ACK can we start assuming that the previous packets were good.. All IMHO Nice find and a good read for anyone.. I am CC'ing the netfilter list as they might like the read.. in case they haven't read it. (Surprised I haven't seen more discussion on this topic) On Thu, 21 Dec 2000, Mike OConnor wrote: > Hi > > I would like to point who ever is in charge of the TCP stack for the linux > kernel at a site which claims to have a method of eliminate denial of > service (DoS) attacks > > http://grc.com/r/nomoredos.htm > > With my limited unstanding of TCP and DoS attacks this would seem to be the > answer, instead of a work around. > -- -------- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 kernels and vpn
Not for a good solution IMHO, run don't walk to FreeS/WAN first, and save yourself a lot of grief On Thu, 21 Dec 2000, John Covici wrote: > Excuse my ignorance, but what is cipe? > > Also, I received a comment that all I had to do was enable gre > tunneling, is this correct? > > -------- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 kernels and vpn
Not for a good solution IMHO, run don't walk to FreeS/WAN first, and save yourself a lot of grief On Thu, 21 Dec 2000, John Covici wrote: Excuse my ignorance, but what is cipe? Also, I received a comment that all I had to do was enable gre tunneling, is this correct? Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No more DoS
Not only is this a well written article, and clearer than most other documents (Even Mine :) but he is dead on track with his basic concepts.. Exactly what I have been looking into over at our company. (Well, close enough) The concept of trusting a SYN packet, has to go.. we have to assume that it is false/bad, and only after receiving the ACK in reply to our SYN/ACK can we start assuming that the previous packets were good.. All IMHO Nice find and a good read for anyone.. I am CC'ing the netfilter list as they might like the read.. in case they haven't read it. (Surprised I haven't seen more discussion on this topic) On Thu, 21 Dec 2000, Mike OConnor wrote: Hi I would like to point who ever is in charge of the TCP stack for the linux kernel at a site which claims to have a method of eliminate denial of service (DoS) attacks http://grc.com/rd/nomoredos.htm With my limited unstanding of TCP and DoS attacks this would seem to be the answer, instead of a work around. -- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No more DoS
Furthermore, it also cannot work because it makes retransmissions of the SYN/ACK very non-workable. I suppose his TCP stack just hacks around this by just waiting for the original client SYN to get retransmitted or something like this. I question whether that can even work reliably. Be interesting to see his response, but in truth, do we care if it gets retransmitted?? When it does, it does... I think not holding onto any state for an incoming SYN is nothing but a dream in any serious modern TCP implementation. It can be reduced, but not eliminated. The former is what most modern stacks have done to fight these problems. A dream, maybe but hey so were most things that we now take for granted.. Worth kicking around a bit tho... Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Signal 11
Sticking my nose where it doesn't belong... On Thu, 14 Dec 2000, Alan Cox wrote: > > Yes, but 2.96 is also binary incompatible with all non-redhat distro's. > > And since redhat is _the_ distro that commercial entities use to > > release software for, this was very arguably a bad move. > o We tell vendors to build RPMv3 , glibc 2.1.x Curious HOW do you tell vendors?? > o Vendors not being stupid understand that they have a bigger market > share if they do that. Ummm.. I remember Oracle's first release... wasn't it JUST redhat?? -- -------- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Signal 11
Sticking my nose where it doesn't belong... On Thu, 14 Dec 2000, Alan Cox wrote: Yes, but 2.96 is also binary incompatible with all non-redhat distro's. And since redhat is _the_ distro that commercial entities use to release software for, this was very arguably a bad move. o We tell vendors to build RPMv3 , glibc 2.1.x Curious HOW do you tell vendors?? o Vendors not being stupid understand that they have a bigger market share if they do that. Ummm.. I remember Oracle's first release... wasn't it JUST redhat?? -- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test12: eth0 trasmit timed out after one hour uptime
On Wed, 13 Dec 2000, Joseph Cheek wrote: > 00:0e.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] > (rev 30) Hmm, maybe I thru it out too fast.. 3Com905B -TXNM XL PCI SN=6xb1b85caf -- ---- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test12: eth0 trasmit timed out after one hour uptime
I wasted time trying to track something similar down, replaced the card instead :> My first clue was when smacking the box, it started working again... (j/k) You didna' mention the card type ... On Wed, 13 Dec 2000, Joseph Cheek wrote: > hi all, > > after about an hour of uptime [and heavy HD usage] my ethernet just > died. couldn't ping a thing. syslog showed: > > Dec 13 14:51:46 sanfrancisco kernel: NETDEV WATCHDOG: eth0: transmit > timed out > Dec 13 14:51:46 sanfrancisco kernel: eth0: transmit timed out, tx_status > 00 status e680. -- -------- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test12: eth0 trasmit timed out after one hour uptime
On Wed, 13 Dec 2000, Joseph Cheek wrote: 00:0e.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30) Hmm, maybe I thru it out too fast.. 3Com905B -TXNM XL PCI SN=6xb1b85caf -- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: syslinux and 2.4.0 initrd size problems
Happily using initrd on a 1.44 floppy here, and there should be no reason why you can't use it for a CDROM distro as well, you can have syslinux on the CDROM too... I believe their is a a syslinux mailing list to check if you have problems, and he has recently released updated versions of syslinux. On Sun, 26 Nov 2000, Jeff V. Merkey wrote: > I am having trouble getting a 2.4 vmlinuz (bzImage) and initrd > image onto a 1.44 floppy with all the new stuff. Even a stipped > down kernel compiled under 2.4 is @ 600K compressed, and I need > about 800K for the initrd image. I noticed that syslinux > has some comments about not allowing initrd to span media. > > I there something more current that does or will allow me to > load the inittrd off a CD-ROM device (with vmlinuz and syslinux > on the floppy). I know how to do this with GRUB (Grand > Unified Boot Loader), but I want to use syslinux if possible. -------- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: syslinux and 2.4.0 initrd size problems
Happily using initrd on a 1.44 floppy here, and there should be no reason why you can't use it for a CDROM distro as well, you can have syslinux on the CDROM too... I believe their is a a syslinux mailing list to check if you have problems, and he has recently released updated versions of syslinux. On Sun, 26 Nov 2000, Jeff V. Merkey wrote: I am having trouble getting a 2.4 vmlinuz (bzImage) and initrd image onto a 1.44 floppy with all the new stuff. Even a stipped down kernel compiled under 2.4 is @ 600K compressed, and I need about 800K for the initrd image. I noticed that syslinux has some comments about not allowing initrd to span media. I there something more current that does or will allow me to load the inittrd off a CD-ROM device (with vmlinuz and syslinux on the floppy). I know how to do this with GRUB (Grand Unified Boot Loader), but I want to use syslinux if possible. Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: reliability of linux-vm subsystem
> up to the sysadmin to enforce the policy. For the home user it means > that the distribution providers have to set decent limits, What is decent today may not be with tommorows' newest softwares > for enterprises it means that they have to hire a sysadmin. That is one of the reasons that small businesses are afraid to go to Linux now, because of the difficulty in finding skilled Linux sysadmins.. "At least with the 'XX' Os, all they need to do is hire someone that can click buttons, either on the computer, or to the tech support line" is the perception, and with Linux they are already worried enough that they have to find a 'genius' to work on their systems fulltime.. It would be nice if 'advanced administration' can be kept to the minimum, so we can service MORE than one enterprise each :> -------- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: reliability of linux-vm subsystem
up to the sysadmin to enforce the policy. For the home user it means that the distribution providers have to set decent limits, What is decent today may not be with tommorows' newest softwares for enterprises it means that they have to hire a sysadmin. That is one of the reasons that small businesses are afraid to go to Linux now, because of the difficulty in finding skilled Linux sysadmins.. "At least with the 'XX' Os, all they need to do is hire someone that can click buttons, either on the computer, or to the tech support line" is the perception, and with Linux they are already worried enough that they have to find a 'genius' to work on their systems fulltime.. It would be nice if 'advanced administration' can be kept to the minimum, so we can service MORE than one enterprise each : -------- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test10-pre3
Hmmm.. Wonder if this might be affecting my problem
I compile on a Pentium for a 486. Worked but after I applied the FreeS/WAN
pathes, now it won't boot on the 486's (immediate reboot, on 'now booting the
kern..' message) Doubled checked the make outputs, and config's and it says
it is 486 but will only run on the Pentiums...
Still reasearching..
On Mon, 16 Oct 2000, Mikael Pettersson wrote:
> On Fri, 13 Oct 2000, Linus Torvalds wrote:
> > - pre3:
> > ...
> >- Dave Jones: x86 setup fixes (recognize Pentium IV etc).
>
> And then in test10-pre3 we find the following code added to
> arch/i386/kernel/setup.c:
>
> + /* Pentium IV. */
> + if (c->x86 == 15) {
> + c->x86 = 6;
> + get_model_name(c);
> + goto name_decoded;
> + }
>
> I believe the "c->x86 = 6" assignment to be broken.
> If it's there to make uname -m return i686 for Pentium IV,
> then surely that could be done differently. (See patch below.)
>
> The assignment throws away perfectly good information, but worse,
> it also destroys the implicit invariant that boot_cpu_data.x86
> equals the "family" code as returned by CPUID. Low-level cpu-specific
> code may then malfunction, or it will have to be updated to do its
> own CPUID identification. Think about MTRRs, model-specific registers,
> performance counters, and bug workarounds.
>
> One harmless example is the "sep_bug" identification code in setup.c:
>
> sep_bug = c->x86_vendor == X86_VENDOR_INTEL &&
> c->x86 == 0x06 &&
> c->cpuid_level >= 0 &&
> (c->x86_capability & X86_FEATURE_SEP) &&
> c->x86_model < 3 &&
> c->x86_mask < 3;
>
> Since initial Pentium IV processors have model 0 according to Intel's
> Pentium IV supplement to the CPUID manual (AP-485), this code may
> actually deduce that a Pentium IV has the bug (if the mask < 3).
> Imagine a similar mistake in an MTRR/MSR/whatever driver...
>
> I propose the following patch against test10-pre3:
>
> --- linux-2.4.0-test10-pre3/arch/i386/kernel/setup.c.~1~ Mon Oct 16
> 17:29:05 2000 +++ linux-2.4.0-test10-pre3/arch/i386/kernel/setup.cMon Oct
> 16 23:13:21 2000 @@ -1548,7 +1548,6 @@
>
> /* Pentium IV. */
> if (c->x86 == 15) {
> - c->x86 = 6;
> get_model_name(c);
> goto name_decoded;
> }
> --- linux-2.4.0-test10-pre3/include/asm-i386/bugs.h.~1~ Sat Sep 9 12:49:40
> 2000 +++ linux-2.4.0-test10-pre3/include/asm-i386/bugs.h Mon Oct 16
> 23:14:42 2000 @@ -426,5 +426,5 @@
> check_pentium_f00f();
> #endif
> check_cyrix_coma();
> - system_utsname.machine[1] = '0' + boot_cpu_data.x86;
> + system_utsname.machine[1] = '0' + (boot_cpu_data.x86 > 6 ? 6 :
> boot_cpu_data.x86); }
>
>
> mtrr.c will need fixing too, but we can't really do that until Intel
> releases a new IA-32 System Programming manual with Pentium IV updates.
>
> /Mikael
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
--
Michael Peddemors - Senior Consultant
Unix Administration - WebSite Hosting
Network Services - Programming
Wizard Internet Services http://www.wizard.ca
Linux Support Specialist - http://www.linuxmagic.com
(604) 589-0037 Beautiful British Columbia, Canada
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: test10-pre3
Hmmm.. Wonder if this might be affecting my problem
I compile on a Pentium for a 486. Worked but after I applied the FreeS/WAN
pathes, now it won't boot on the 486's (immediate reboot, on 'now booting the
kern..' message) Doubled checked the make outputs, and config's and it says
it is 486 but will only run on the Pentiums...
Still reasearching..
On Mon, 16 Oct 2000, Mikael Pettersson wrote:
On Fri, 13 Oct 2000, Linus Torvalds wrote:
- pre3:
...
- Dave Jones: x86 setup fixes (recognize Pentium IV etc).
And then in test10-pre3 we find the following code added to
arch/i386/kernel/setup.c:
+ /* Pentium IV. */
+ if (c-x86 == 15) {
+ c-x86 = 6;
+ get_model_name(c);
+ goto name_decoded;
+ }
I believe the "c-x86 = 6" assignment to be broken.
If it's there to make uname -m return i686 for Pentium IV,
then surely that could be done differently. (See patch below.)
The assignment throws away perfectly good information, but worse,
it also destroys the implicit invariant that boot_cpu_data.x86
equals the "family" code as returned by CPUID. Low-level cpu-specific
code may then malfunction, or it will have to be updated to do its
own CPUID identification. Think about MTRRs, model-specific registers,
performance counters, and bug workarounds.
One harmless example is the "sep_bug" identification code in setup.c:
sep_bug = c-x86_vendor == X86_VENDOR_INTEL
c-x86 == 0x06
c-cpuid_level = 0
(c-x86_capability X86_FEATURE_SEP)
c-x86_model 3
c-x86_mask 3;
Since initial Pentium IV processors have model 0 according to Intel's
Pentium IV supplement to the CPUID manual (AP-485), this code may
actually deduce that a Pentium IV has the bug (if the mask 3).
Imagine a similar mistake in an MTRR/MSR/whatever driver...
I propose the following patch against test10-pre3:
--- linux-2.4.0-test10-pre3/arch/i386/kernel/setup.c.~1~ Mon Oct 16
17:29:05 2000 +++ linux-2.4.0-test10-pre3/arch/i386/kernel/setup.cMon Oct
16 23:13:21 2000 @@ -1548,7 +1548,6 @@
/* Pentium IV. */
if (c-x86 == 15) {
- c-x86 = 6;
get_model_name(c);
goto name_decoded;
}
--- linux-2.4.0-test10-pre3/include/asm-i386/bugs.h.~1~ Sat Sep 9 12:49:40
2000 +++ linux-2.4.0-test10-pre3/include/asm-i386/bugs.h Mon Oct 16
23:14:42 2000 @@ -426,5 +426,5 @@
check_pentium_f00f();
#endif
check_cyrix_coma();
- system_utsname.machine[1] = '0' + boot_cpu_data.x86;
+ system_utsname.machine[1] = '0' + (boot_cpu_data.x86 6 ? 6 :
boot_cpu_data.x86); }
mtrr.c will need fixing too, but we can't really do that until Intel
releases a new IA-32 System Programming manual with Pentium IV updates.
/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
--
--------
Michael Peddemors - Senior Consultant
Unix Administration - WebSite Hosting
Network Services - Programming
Wizard Internet Services http://www.wizard.ca
Linux Support Specialist - http://www.linuxmagic.com
(604) 589-0037 Beautiful British Columbia, Canada
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Standard Linux (Was What is up with Redhat 7.0?)
On Sat, 30 Sep 2000, Marc Lehmann wrote: > However, I think attacking other free softwrae projects because of *bugs* > is just childish at this point - after all, this discussion was about > supporting distributions that - without technical reasons - make their > products incompatible to what one would call "standard linux", and that I > do not think that the kernel should support such doings. > That RedHat Thread was degrading into a name calling match... But it does have one core element that maybe should be discussed, and that can be a relevant and productive discussion for this list. 'Standard Linux' Should the core kernel define a standard Linux?? And what does the community think of distros that veer from the standard? Should the 'standard' be set in stone? ie should we say that ALL distros have to ship with, and be compatible with the standard kernel? If a distro has a patch that they want in the kernel, and the mainstream kernel doesn't feel it belongs, should it be labeled differently? Do we go with a Debian Linux, Redhat Linux, etc.. accepting that they are all different, but from a common heritage or should there be a 'seal of approval' so that a distro can indicate it is 100% linux mainstream, as in SomeDistro Linux, '100% Linux Standard Compliant' Thoughts?? I know our Linux Distro is non-conformant because of our FreeS/WAN and encryption patches.. Yes, we are still Linux, but I know we shouldn't get the '100% ...Compliant' label.. Of course, from a marketing standpoint, I would hate to carry that stigma, but I think it is prudent that our customers have the right to know that their experience with other Linux's may not be sufficient, or that down the road they may be forced to use us for support, or get/buy 'LinuxMagic' software rather than '100% Compliant' versions of the software if we choose to not be compliant. That is the risk of using our product if we are not compliant, even if we perhaps happen, or claim to be the best/greatest/fastest thing since sliced bread, and blow away the '100% Compliant' version. At that point we aren't really Linux but a Linux variant that is still opensource, uses the Linux metholdolgy, and albeit a close dirivitive.. but still not really Linux.. Some companies are using 'open-source' monickers as a marketing ploy... As if 'open-source' means that it is some sort of industry standard.. And although the freedom of open source in the development community means great things for all, the end consumer wants standards. Maybe it is time that standards, (And accepting patches or changes to the kernel while rejecting others IS a standard whether we call it such or not) are openly claimed to be such, even if those standards are dictated by Linus himself, the community at large by consensus, or a representing body. Either that or I see a very real possiblilty of fragmentation of the development of Linux products as the corporate needs start to dictate what 'Linux' is.. Oh, and don't get me wrong, fragmentation will happen as two people differ on what they think is best.. Otherwise we wouldn't have so many flavours of Unices out there too. Some guys at Berkely might still be dictating their thoughts of what is best.. and we would all be using it.. Linus?? I wouldn't mind hearing you thoughts on formally declaring a 'standard' on kernels..rather than an assumption that it is :> (Side Note: had one of my sysadmins that needed to install a server with a DAC960 Raid controller.. The standard Linux kernel had no support for it so he had a choice. Patch it, or use the RedHat version. Do we say that this controller is not supported by Linux, but is supported by RedHat Linux? Are we not then saying we have two different OS's??) -------- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Standard Linux (Was What is up with Redhat 7.0?)
On Sat, 30 Sep 2000, Marc Lehmann wrote: However, I think attacking other free softwrae projects because of *bugs* is just childish at this point - after all, this discussion was about supporting distributions that - without technical reasons - make their products incompatible to what one would call "standard linux", and that I do not think that the kernel should support such doings. That RedHat Thread was degrading into a name calling match... But it does have one core element that maybe should be discussed, and that can be a relevant and productive discussion for this list. 'Standard Linux' Should the core kernel define a standard Linux?? And what does the community think of distros that veer from the standard? Should the 'standard' be set in stone? ie should we say that ALL distros have to ship with, and be compatible with the standard kernel? If a distro has a patch that they want in the kernel, and the mainstream kernel doesn't feel it belongs, should it be labeled differently? Do we go with a Debian Linux, Redhat Linux, etc.. accepting that they are all different, but from a common heritage or should there be a 'seal of approval' so that a distro can indicate it is 100% linux mainstream, as in SomeDistro Linux, '100% Linux Standard Compliant' Thoughts?? I know our Linux Distro is non-conformant because of our FreeS/WAN and encryption patches.. Yes, we are still Linux, but I know we shouldn't get the '100% ...Compliant' label.. Of course, from a marketing standpoint, I would hate to carry that stigma, but I think it is prudent that our customers have the right to know that their experience with other Linux's may not be sufficient, or that down the road they may be forced to use us for support, or get/buy 'LinuxMagic' software rather than '100% Compliant' versions of the software if we choose to not be compliant. That is the risk of using our product if we are not compliant, even if we perhaps happen, or claim to be the best/greatest/fastest thing since sliced bread, and blow away the '100% Compliant' version. At that point we aren't really Linux but a Linux variant that is still opensource, uses the Linux metholdolgy, and albeit a close dirivitive.. but still not really Linux.. Some companies are using 'open-source' monickers as a marketing ploy... As if 'open-source' means that it is some sort of industry standard.. And although the freedom of open source in the development community means great things for all, the end consumer wants standards. Maybe it is time that standards, (And accepting patches or changes to the kernel while rejecting others IS a standard whether we call it such or not) are openly claimed to be such, even if those standards are dictated by Linus himself, the community at large by consensus, or a representing body. Either that or I see a very real possiblilty of fragmentation of the development of Linux products as the corporate needs start to dictate what 'Linux' is.. Oh, and don't get me wrong, fragmentation will happen as two people differ on what they think is best.. Otherwise we wouldn't have so many flavours of Unices out there too. Some guys at Berkely might still be dictating their thoughts of what is best.. and we would all be using it.. Linus?? I wouldn't mind hearing you thoughts on formally declaring a 'standard' on kernels..rather than an assumption that it is : (Side Note: had one of my sysadmins that needed to install a server with a DAC960 Raid controller.. The standard Linux kernel had no support for it so he had a choice. Patch it, or use the RedHat version. Do we say that this controller is not supported by Linux, but is supported by RedHat Linux? Are we not then saying we have two different OS's??) -------- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Oops when vim exits, and connection problems
Now this is why we read the archives first... This will surely be a FAQ soon enough.. The short answer is it isn't the kernel that is screwy, it is the site(s)/routers. Also look at the docs re Explicit Congestion Notification On Sun, 24 Sep 2000, J Brook wrote: > On Sun 24 Sep 2000 Derrik Pates wrote: > >- I am unable to connect to several sites, including > >cisco.netacad.net and www.hotmail.com. I always receive a "connection > >refused". It seems weird, but with 2.2.18pre10, I could connect, and > >with 2.4.0-test8, I can't. > > I get similar behaviour on my box (RH6.2 kernel 2.4.0-t9p5). I am > able to call up the hotmail homepage using Netscape, but am unable to > login. More crucially I am unable to send email (using qmail) to > hotmail addresses when running the latest kernels (I've noticed this > problem since test8 - I was going to email hotmail about it, but > seeing as how it's come up here!) However, I am able to connect > without any problems using my 2.2.16 kernel, and I am also able to > send emails to hotmail addresses using qmail using that kernel. > > Instructions describing how to gather more useful information would > be welcome (or pointers to where the relevant instructions are :-) > > John > > [EMAIL PROTECTED] > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Oops when vim exits, and connection problems
Now this is why we read the archives first... This will surely be a FAQ soon enough.. The short answer is it isn't the kernel that is screwy, it is the site(s)/routers. Also look at the docs re Explicit Congestion Notification On Sun, 24 Sep 2000, J Brook wrote: On Sun 24 Sep 2000 Derrik Pates wrote: - I am unable to connect to several sites, including cisco.netacad.net and www.hotmail.com. I always receive a "connection refused". It seems weird, but with 2.2.18pre10, I could connect, and with 2.4.0-test8, I can't. I get similar behaviour on my box (RH6.2 kernel 2.4.0-t9p5). I am able to call up the hotmail homepage using Netscape, but am unable to login. More crucially I am unable to send email (using qmail) to hotmail addresses when running the latest kernels (I've noticed this problem since test8 - I was going to email hotmail about it, but seeing as how it's come up here!) However, I am able to connect without any problems using my 2.2.16 kernel, and I am also able to send emails to hotmail addresses using qmail using that kernel. Instructions describing how to gather more useful information would be welcome (or pointers to where the relevant instructions are :-) John [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ -- -------- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Tone of the Race to 2.4....
Seems a little like people are racing to get this kernel out.. and getting frustrated with the little things that keep cropping up.. Sounds so much like our business where it was starting to seem like we were racing from one fire to another, and wondering how come we got to that point.. The way we got back on track was to remember the basics.. And FORCE ourselves to make time to do them ALL, or don't do it at all.. Looking back is easier, and we can see that we let these basics slip..the basics we agree need to be done are... 1) Does it work?? 2) Is it tested? 3) Does it look pretty?? (syntactically, comments, and flow...) 4) Looking back in hindsight, could I have done it in a better way?? The more often we let ourselves get to the point where we start sacrificing 2,3, and 4, the more fires we have to put out, the less time we seem to have, and we use that as justification to let 2,3, and 4 slide even more.. Pretty soon we are in catch 22 land... Sometimes forcing ourselves to slow down, actually ends up saving time... and we think a lot clearer too.. Just an observation from the sidelines.. And not pointing any fingers.. Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Tone of the Race to 2.4....
Seems a little like people are racing to get this kernel out.. and getting frustrated with the little things that keep cropping up.. Sounds so much like our business where it was starting to seem like we were racing from one fire to another, and wondering how come we got to that point.. The way we got back on track was to remember the basics.. And FORCE ourselves to make time to do them ALL, or don't do it at all.. Looking back is easier, and we can see that we let these basics slip..the basics we agree need to be done are... 1) Does it work?? 2) Is it tested? 3) Does it look pretty?? (syntactically, comments, and flow...) 4) Looking back in hindsight, could I have done it in a better way?? The more often we let ourselves get to the point where we start sacrificing 2,3, and 4, the more fires we have to put out, the less time we seem to have, and we use that as justification to let 2,3, and 4 slide even more.. Pretty soon we are in catch 22 land... Sometimes forcing ourselves to slow down, actually ends up saving time... and we think a lot clearer too.. Just an observation from the sidelines.. And not pointing any fingers.. Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9-pre2
On Sun, 17 Sep 2000, Mark Orr wrote: > Has anyone else tried 240-test9-pre2 on low-memory systems? Hmmm... I am getting periodic hangs on reading floppies AFTER initrd inititialization Maybe once every 20 boots.. same thing.. strange hang, and a control gets by whatever process was hanging and it continues... Thought it was maybe a floppy hardware read issue, but wondering... -- ---- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9-pre2
On Sun, 17 Sep 2000, Mark Orr wrote: Has anyone else tried 240-test9-pre2 on low-memory systems? Hmmm... I am getting periodic hangs on reading floppies AFTER initrd inititialization Maybe once every 20 boots.. same thing.. strange hang, and a control c gets by whatever process was hanging and it continues... Thought it was maybe a floppy hardware read issue, but wondering... -- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[OOPS] in 2.4.0-test8 occuring in low memory machines
Sorry I can't be more explicit in checking this out, still working my way through definitive situations where these occur, but seem to be in low memory machines, running initrd.gz minix filesystems.. I started gettting OOPS soon after running a patch to rd.c to allow for encrypted initrd.gz, and I thought it was something to do with the patch, but it seems this is a deeper issue, because we are now getting it even when using an unencrypted initrd.gz. Only seems to happen on Pentium/486 class machines with 8-16 MG RAM Also, we are running a minix file system. First OOPS occured after gunzip routine completed, while using the encrypted initrd.gz.. (Unencrypted OOPS below) Not a master of ksymoops, but included it incase it helps. Unable to handle kernel paging request at virtual address 8140c35b printing eip: c015e483 *pde = Oops: CPU:0 EIP:0010:[] EFLAGS: 00010293 eax: 8140c357 ebx: 8140c35f ecx: c10952d0 edx: c10951d0 esi: 0042 edi: ebp: 000a esp: c1ffd824 ds: 0018es: 0018ss: 0018 Process swapper (pid: 1, stackpage=c1ffd000) Stack: 0008 c015f1e4 c1f04008 0005 001d c1ffdd8c c1ffd874 c1ffd870 c1ffd86c 001e 011e 0012 013c 007f c1f19408 0006 c1f04008 0009 0005 0006 0007 0007 Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 8b 58 04 50 e8 44 78 05 00 89 d8 83 c4 04 85 c0 75 eb 31 c0 Kernel panic: Attempted to kill init! >>EIP; c015e483<= Trace; c015f1e4 Trace; c015f2e9 Trace; f0708b1f Trace; c015f366 Trace; f0708b1f Trace; c015f753 Trace; c011a28d Trace; c0100018 Trace; c01070e7 Trace; c0107518 Code; c015e483 <_EIP>: Code; c015e483<= 0: 8b 58 04 movl 0x4(%eax),%ebx <= Code; c015e486 3: 50pushl %eax Code; c015e487 4: e8 44 78 05 00call 5784d <_EIP+0x5784d> c01b5cd0 Code; c015e48c 9: 89 d8 movl %ebx,%eax Code; c015e48e b: 83 c4 04 addl $0x4,%esp Code; c015e491 e: 85 c0 testl %eax,%eax Code; c015e493 10: 75 eb jnefffd <_EIP+0xfffd> c015e480 Code; c015e495 12: 31 c0 xorl %eax,%eax Latest OOPS discovered Unable to handle kernel paging request at virtual address c839a5b4 printing eip: c8124c70 *pde = Oops: CPU:0 EIP:0010:[] EFLAGS: 00010282 eax: ebx: c839a5b0 ecx: 400ec000 edx: c020f360 esi: 400e8000 edi: c020f360 ebp: 0004 esp: c0097f90 ds: 0018es: 0018ss: 0018 Process kswapd (pid: 2, stackpage=c0097000) Stack: c020f360 0015 c0124d51 c020f360 0004 0010 0027 0008 0028 0054 c0124f0c 0028 0004 00010f00 0003 0001 0008e000 c0125038 0004 c009bf98 Call Trace: [] [] [] [] Code: 8b 73 04 55 56 53 57 e8 24 fe ff ff 83 c4 10 85 c0 75 1d 8b ksymoops output Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010282 eax: ebx: c839a5b0 ecx: 400ec000 edx: c020f360 esi: 400e8000 edi: c020f360 ebp: 0004 esp: c0097f90 ds: 0018es: 0018 ss: 0018 Process kswapd (pid: 2, stackpage=c0097000) Stack: c020f360 0015 c0124d51 c020f360 0004 0010 0027 0008 0028 0054 c0124f0c 0028 0004 00010f00 0003 0001 0008e000 c0125038 0004 c009bf98 Call Trace: [] [] [] [] Code: 8b 73 04 55 56 53 57 e8 24 fe ff ff 83 c4 10 85 c0 75 1d 8b >>EIP; c0124c70<= Trace; c0124d51 Trace; c0124f0c Trace; c0125038 Trace; c0107518 Code; c0124c70 <_EIP>: Code; c0124c70<= 0: 8b 73 04 movl 0x4(%ebx),%esi <= Code; c0124c73 3: 55pushl %ebp Code; c0124c74 4: 56pushl %esi Code; c0124c75 5: 53pushl %ebx Code; c0124c76 6: 57pushl %edi Code; c0124c77 7: e8 24 fe ff ffcall fe30 <_EIP+0xfe30> c0124aa0 Code; c0124c7c c: 83 c4 10 addl $0x10,%esp Code; c0124c7f f: 85 c0 testl %eax,%eax Code; c0124c81 11: 75 1d jne30 <_EIP+0x30> c0124ca0 Code; c0124c83 13: 8b 00 movl (%eax),%eax 1 warning and 1 error issued. Results may not be reliable. Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com ---
MakeFile Problems - make modules_install test8
Last time I hit this I just ignored it, but it is still in test8
When running `make modules_install` it errors out with an
cd /lib/modules/2.4.0-test8; \
mkdir -p pcmcia; \
find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia
if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.4.0-test8; fi
modprobe: kernel: QM_SYMBOLS: Function not implemented
make: *** [_modinst_post] Error 1
even tho pcmcia was never defined in the .config
Have to remove the _modinst_post in the `make modules_install` in order to
complete
Michael Peddemors - Senior Consultant
Unix Administration - WebSite Hosting
Network Services - Programming
Wizard Internet Services http://www.wizard.ca
Linux Support Specialist - http://www.linuxmagic.com
(604) 589-0037 Beautiful British Columbia, Canada
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
MakeFile Problems - make modules_install test8
Last time I hit this I just ignored it, but it is still in test8
When running `make modules_install` it errors out with an
cd /lib/modules/2.4.0-test8; \
mkdir -p pcmcia; \
find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia
if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.4.0-test8; fi
modprobe: kernel: QM_SYMBOLS: Function not implemented
make: *** [_modinst_post] Error 1
even tho pcmcia was never defined in the .config
Have to remove the _modinst_post in the `make modules_install` in order to
complete
Michael Peddemors - Senior Consultant
Unix Administration - WebSite Hosting
Network Services - Programming
Wizard Internet Services http://www.wizard.ca
Linux Support Specialist - http://www.linuxmagic.com
(604) 589-0037 Beautiful British Columbia, Canada
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[OOPS] in 2.4.0-test8 occuring in low memory machines
: e8 24 fe ff ffcall fe30 _EIP+0xfe30 c0124aa0 swap_out_vma+0/1a0 Code; c0124c7c swap_out_mm+3c/70 c: 83 c4 10 addl $0x10,%esp Code; c0124c7f swap_out_mm+3f/70 f: 85 c0 testl %eax,%eax Code; c0124c81 swap_out_mm+41/70 11: 75 1d jne30 _EIP+0x30 c0124ca0 swap_out_mm+60/70 Code; c0124c83 swap_out_mm+43/70 13: 8b 00 movl (%eax),%eax 1 warning and 1 error issued. Results may not be reliable. Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux kernel TCP, network connections and iptables
On Thu, 07 Sep 2000, George Athanassopoulos wrote: Possibly post this message on the netfilter mailing list. [EMAIL PROTECTED] Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux kernel TCP, network connections and iptables
On Thu, 07 Sep 2000, George Athanassopoulos wrote: Possibly post this message on the netfilter mailing list. [EMAIL PROTECTED] Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: making it hard (was kdb)
On Wed, 06 Sep 2000, Linus Torvalds wrote: When searching out some Venture Capital a while back, I heard the same words... We make it hard to get money intentionally, if you get frustrated, well you aren't the type of person that we want running the companies we invest in Oooops.. thread digressing.. > The people, the projects, the companies that come though that test of > fire victorious are not only stronger for it, but more importantly, they > are the kind of people, projects adn companies who DID get through. > Dedicated. Smart. And careful. > Linus -- -------- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
On Wed, 06 Sep 2000, Linus Torvalds wrote: > And quite frankly, I don't care. I don't think kernel development should > be "easy". I do not condone single-stepping through code to find the bug. > I do not think that extra visibility into the system is necessarily a good > thing. Okay, so you have valid args there, but if we (you) aren't going to make it easy, what kind of concerted effort is there to entice people to work on kernel development.. Takes a rare breed to like doing things the hard way, and when those few new ones pop up, how do we encourage them to be kernel gurus. Is there any sort of plan to help newbie kernel programmers to get to the point where the Linus's and Alan's of the world will take them under their wings? Should this be thought of in kernel development circles? A kernel development school? Kernel Development Courses that teach the followings of the leaders? A manifesto? A book about 'So you want to be a Linux Kernel Programmer?' I agree that standards have to be adhered to, and maybe only the tough should survive, but if we agree that it shouldn't be simple, then I think it is the obligation to figure out some other way to lend a helping hand, or we will find the list of developers growing smaller, while the learning curve gets ever greater. In the 0.98 days when I started, a relative newbie had a chance to come in and follow your coding, but now the curve in getting to the point where they can contribute effectively, and following your standards gets ever steeper. The days where Linus himself could teach a few clerics what he knows quickly is dissapearing.. Maybe thought should be taken not only to the long term direction of the code, but in the long term development of new coders. > Apparently, if you follow the arguments, not having a kernel debugger > leads to various maladies: > - people have given up on Linux kernel programming because it's too hard >and too time-consuming > And nobody has explained to me why these are _bad_ things. > Because I'm a bastard, and proud of it! > > Linus Any general thoughts on how to keep recruiting the next generation of bastards? -------- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: making it hard (was kdb)
On Wed, 06 Sep 2000, Linus Torvalds wrote: When searching out some Venture Capital a while back, I heard the same words... We make it hard to get money intentionally, if you get frustrated, well you aren't the type of person that we want running the companies we invest in Oooops.. thread digressing.. The people, the projects, the companies that come though that test of fire victorious are not only stronger for it, but more importantly, they are the kind of people, projects adn companies who DID get through. Dedicated. Smart. And careful. Linus -- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Screen corruption on startup 2.4.0-test7
Now I might as well put in my two bits on another annoyance 2.4.0-test7 no longer displays (vidmode bzImage 8, and passing vga=8 via syslinux) the same as earlier kernels. I get a wrapped extra line on the bottom, and on the first scroll thru I get all kinds of pretty colours on the extra line. Just an annoyance, and haven't had time to chase it down.. Just thought I would mention it, in case this is a similar issue. Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Chat Servers - Respond Off Channel Please
Everyone here can use IRC, but I want to also create a place where new developers are encouraged to join the movement. Well, a lot of people don't use IRC at all.. I wanted to make a simple yet easy to use communication forum. Anyone can use this, (in principle) Just wanted to have a central location for ANYONE who wants to learn about Linux, as well as real time workspace for developers... Also, want to have it tied into a website so that events can be advertised etc.. (IE it would be nice for new developers to chat with the more senior deveopers..) Judging by how many people went into the chat over night to take a look, it seems that a lot of people would like a central location for chats.. On Sat, 02 Sep 2000, Gerhard Mack wrote: > And the problem with irc.openprojects.net is ... ? ---- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Chat Servers - Respond Off Channel Please
Everyone here can use IRC, but I want to also create a place where new developers are encouraged to join the movement. Well, a lot of people don't use IRC at all.. I wanted to make a simple yet easy to use communication forum. Anyone can use this, (in principle) Just wanted to have a central location for ANYONE who wants to learn about Linux, as well as real time workspace for developers... Also, want to have it tied into a website so that events can be advertised etc.. (IE it would be nice for new developers to chat with the more senior deveopers..) Judging by how many people went into the chat over night to take a look, it seems that a lot of people would like a central location for chats.. On Sat, 02 Sep 2000, Gerhard Mack wrote: And the problem with irc.openprojects.net is ... ? Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Screen corruption on startup 2.4.0-test7
Now I might as well put in my two bits on another annoyance 2.4.0-test7 no longer displays (vidmode bzImage 8, and passing vga=8 via syslinux) the same as earlier kernels. I get a wrapped extra line on the bottom, and on the first scroll thru I get all kinds of pretty colours on the extra line. Just an annoyance, and haven't had time to chase it down.. Just thought I would mention it, in case this is a similar issue. Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Linux Chat Servers
Sorta off the topic, but just setup a 'Chat Room' For Linux Specific Topics... If it is useful, we will expand the concept and set it up on a dedicated server etc.. http://www.linuxmagic.com/chat CHAT For Linux Only Thought it would be nice for some people to hash out some of these ideas in real time.. We havent' load tested this particular setup, but if all of a sudden thousands of people start using it, well I guess that means the service is needed, and we will do what it takes to satisfy everyone.. Only the Java Enabled browsers can take advantage of it so far, but again, if the service gets used, I definitley will add telnet support.. .. Feel free to use it as much as you want.. It will stay live.. No matter if only 2 people find it useful, or thousands.. Would be nice if we could get weekly chats together on say kernel development? Hope I haven't wasted our time with this, but it seemed that judging by some of the threads, a quick chat could have sorted things out a lot quicker... BTW, our HTML guys haven't been able to keep up with everything and we hurried a little to get this out there.. so I apologize in advance if anyone notices some flaws or errors. If any problems using the chat PLEASE LET US KNOW right away. Thanks Again, URL is http://linuxmagic.com/chat Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Problem booting 2.4.0-test series
I have seen strange problems sometimes with using menuconfig or xconfig completely go away when creating my config as simply `make config` Sometimes a strange dependency comes in.. Since your problem is a little vague, and seems to be on a generic paltform, I would suggest that it is a problem with the compilation procedures. Narrow that down first. On Wed, 31 Dec 1969, root wrote: > With all of 2.4.0-test series, and at least 2.3.51, I've been unable to > boot. I'm in the process of getting other 2.3 kernels, to see where the > problem was introduced. > > My PC hangs after "OK, booting the kernel". I have a pentium, but this > problem occurs whether I configure the kernel as pentium, 486 or 386. > > I've never had a problem with the 2.2 series, and currently use 2.2.16. Can > anyone suggest a way for me to track down this problem. I cant really debug > tanything, since I hang before the boot process is anywhere near complete. > > Any suggestions gratefully received. -- -------- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
