Re: Suspend-to-disk woes
On Saturday 19 March 2005 13:29, Pavel Machek wrote: > On So 19-03-05 12:20:35, Russell Miller wrote: > > On Saturday 19 March 2005 05:26, Pavel Machek wrote: > > > Checking that would be hard, but you might want to provide patch to > > > check last-mounted dates of filesystems and panic if they changed. > > > Pavel > > > > Then how would you fix it? There'd also have to be a way to reset it, > > boot with "noresume", then mkswap. > Pavel Ah, makes sense. I've never used the resume functionality, so my ignorance on that subject is understandable... :-) --Russell -- Russell Miller - [EMAIL PROTECTED] - Agoura, CA - 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: Suspend-to-disk woes
On Saturday 19 March 2005 05:26, Pavel Machek wrote: > Checking that would be hard, but you might want to provide patch to check > last-mounted dates of filesystems and panic if they changed. > Pavel Then how would you fix it? There'd also have to be a way to reset it, otherwise the kernel will never boot again. Perhaps an argument to the kernel that allows for resetting of the mechanism? --Russell -- Russell Miller - [EMAIL PROTECTED] - Agoura, CA - 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: Suspend-to-disk woes
On Saturday 19 March 2005 05:26, Pavel Machek wrote: Checking that would be hard, but you might want to provide patch to check last-mounted dates of filesystems and panic if they changed. Pavel Then how would you fix it? There'd also have to be a way to reset it, otherwise the kernel will never boot again. Perhaps an argument to the kernel that allows for resetting of the mechanism? --Russell -- Russell Miller - [EMAIL PROTECTED] - Agoura, CA - 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: Suspend-to-disk woes
On Saturday 19 March 2005 13:29, Pavel Machek wrote: On So 19-03-05 12:20:35, Russell Miller wrote: On Saturday 19 March 2005 05:26, Pavel Machek wrote: Checking that would be hard, but you might want to provide patch to check last-mounted dates of filesystems and panic if they changed. Pavel Then how would you fix it? There'd also have to be a way to reset it, boot with noresume, then mkswap. Pavel Ah, makes sense. I've never used the resume functionality, so my ignorance on that subject is understandable... :-) --Russell -- Russell Miller - [EMAIL PROTECTED] - Agoura, CA - 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/
auditing subsystem
I've been doing a lot of research on this, and I keep coming up with things that don't work, have been abandoned, or are almost impossible to find or get working. So I'll ask here. Maybe one of the ultra-elightened linux gods will have a ready answer. I want to be able to audit system calls - I want to log when files are opened, created, changed, deleted, etc. Preferably I would like to do it without having to apply kernel patches, using vanilla (or close to vanilla) kernel. If this isn't possible, my net preference is to use a module. If this isn't possible, well, I'll do what I have to. I notice there is a CONFIG_AUDIT option. Is this what I am looking for, and how do I use it? /dev/audit seems not to work... Thanks. If you can even point me a suitable FM to R, I'd be content. --Russell -- Russell Miller - [EMAIL PROTECTED] - Agoura, CA - 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.6.11 vs DVB cx88 stuffs
On Thursday 03 March 2005 18:45, Andrew Morton wrote: > Gene Heskett <[EMAIL PROTECTED]> wrote: > > I've a new pcHDTV-3000 card, and I thought maybe it would > > be a good idea to build the cx88 stuff in the DVB section > > of a make xconfig. > > > > It doesn't build, spitting out this bailout: > > > >CC [M] drivers/media/video/cx88/cx88-cards.o > > drivers/media/video/cx88/cx88-cards.c: In function > > `hauppauge_eeprom_dvb': drivers/media/video/cx88/cx88-cards.c:694: error: > > `PLLTYPE_DTT7595' undeclared (first use in this function) > > drivers/media/video/cx88/cx88-cards.c:694: error: (Each undeclared > > identifier is reported only once > > drivers/media/video/cx88/cx88-cards.c:694: error: for each function it > > appears in.) drivers/media/video/cx88/cx88-cards.c:698: error: > > `PLLTYPE_DTT7592' undeclared (first use in this function) > > drivers/media/video/cx88/cx88-cards.c: In function `cx88_card_setup': > > drivers/media/video/cx88/cx88-cards.c:856: error: `PLLTYPE_DTT7579' > > undeclared (first use in this function) make[4]: *** > > [drivers/media/video/cx88/cx88-cards.o] Error 1 > > make[3]: *** [drivers/media/video/cx88] Error 2 > > make[2]: *** [drivers/media/video] Error 2 > > .config, please. > - I have the same problem. Here is mine. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11 # Wed Mar 2 15:49:02 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # CONFIG_CLEAN_COMPILE is not set CONFIG_BROKEN=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_FUTEX=y CONFIG_EPOLL=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y # CONFIG_HPET_TIMER is not set # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y # CONFIG_X86_UP_APIC is not set CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_MICROCODE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y # CONFIG_HIGHPTE is not set CONFIG_MATH_EMULATION=y CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_HAVE_DEC_LOCK=y # CONFIG_REGPARM is not set # # Power management options (ACPI, APM) # # CONFIG_PM is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=m CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_THERMAL=m CONFIG_ACPI_ASUS=m CONFIG_ACPI_IBM=m CONFIG_ACPI_TOSHIBA=m CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y # CONFIG_X86_PM_TIMER is not set CONFIG_ACPI_CONTAINER=m # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set
Re: 2.6.11 vs DVB cx88 stuffs
On Thursday 03 March 2005 18:45, Andrew Morton wrote: Gene Heskett [EMAIL PROTECTED] wrote: I've a new pcHDTV-3000 card, and I thought maybe it would be a good idea to build the cx88 stuff in the DVB section of a make xconfig. It doesn't build, spitting out this bailout: CC [M] drivers/media/video/cx88/cx88-cards.o drivers/media/video/cx88/cx88-cards.c: In function `hauppauge_eeprom_dvb': drivers/media/video/cx88/cx88-cards.c:694: error: `PLLTYPE_DTT7595' undeclared (first use in this function) drivers/media/video/cx88/cx88-cards.c:694: error: (Each undeclared identifier is reported only once drivers/media/video/cx88/cx88-cards.c:694: error: for each function it appears in.) drivers/media/video/cx88/cx88-cards.c:698: error: `PLLTYPE_DTT7592' undeclared (first use in this function) drivers/media/video/cx88/cx88-cards.c: In function `cx88_card_setup': drivers/media/video/cx88/cx88-cards.c:856: error: `PLLTYPE_DTT7579' undeclared (first use in this function) make[4]: *** [drivers/media/video/cx88/cx88-cards.o] Error 1 make[3]: *** [drivers/media/video/cx88] Error 2 make[2]: *** [drivers/media/video] Error 2 .config, please. - I have the same problem. Here is mine. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11 # Wed Mar 2 15:49:02 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # CONFIG_CLEAN_COMPILE is not set CONFIG_BROKEN=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y # # General setup # CONFIG_LOCALVERSION= CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_FUTEX=y CONFIG_EPOLL=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y # CONFIG_HPET_TIMER is not set # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y # CONFIG_X86_UP_APIC is not set CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_MICROCODE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y # CONFIG_HIGHPTE is not set CONFIG_MATH_EMULATION=y CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_HAVE_DEC_LOCK=y # CONFIG_REGPARM is not set # # Power management options (ACPI, APM) # # CONFIG_PM is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=m CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_THERMAL=m CONFIG_ACPI_ASUS=m CONFIG_ACPI_IBM=m CONFIG_ACPI_TOSHIBA=m CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y # CONFIG_X86_PM_TIMER is not set CONFIG_ACPI_CONTAINER=m # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set #
auditing subsystem
I've been doing a lot of research on this, and I keep coming up with things that don't work, have been abandoned, or are almost impossible to find or get working. So I'll ask here. Maybe one of the ultra-elightened linux gods will have a ready answer. I want to be able to audit system calls - I want to log when files are opened, created, changed, deleted, etc. Preferably I would like to do it without having to apply kernel patches, using vanilla (or close to vanilla) kernel. If this isn't possible, my net preference is to use a module. If this isn't possible, well, I'll do what I have to. I notice there is a CONFIG_AUDIT option. Is this what I am looking for, and how do I use it? /dev/audit seems not to work... Thanks. If you can even point me a suitable FM to R, I'd be content. --Russell -- Russell Miller - [EMAIL PROTECTED] - Agoura, CA - 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: RFD: Kernel release numbering
On Wednesday 02 March 2005 20:58, David S. Miller wrote: > That's one of the major things the -rc's don't get. Maybe it gets > a reference in lwn.net's weekly kernel article, but mostly kernel > geeks read those and that's not who we want testing -rc's (such > geeks already are doing so). > How do you know that they won't stop the announcements if this change is made? --Russell -- Russell Miller - [EMAIL PROTECTED] - Agoura, CA - 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: RFD: Kernel release numbering
On Wednesday 02 March 2005 19:37, Linus Torvalds wrote: > That's the whole point here, at least to me. I want to have people test > things out, but it doesn't matter how many -rc kernels I'd do, it just > won't happen. It's not a "real release". > > In contrast, making it a real release, and making it clear that it's a > release in its own right, might actually get people to use it. > > Might. Maybe. > Linus, I respect all of the work you have done on the Linux kernels over the years, and I have been an avid user of Linux almost since its inception (when I could get it to work with the hardware, at least in the early days ;-) And the fact that my contributions to the kernel are almost nonexistent probbly means you won't pay attention to a word I say anyway :-) that's alright, I'm going to say it and you can listen if you want. My respect for your accomplishments is why it pains me a great deal to have to tell you that I think you're wrong. I agree with the first part of your mail that I quoted above. Indeed, the -rc releases are not a "real release", and therefore people aren't going to test it. What you are missing is that if you use the method you have proposed. odd numberered kernels will stop being a "real release" as well to a great deal of users. I don't think you will actually gain anything here except for just changing the kernel naming scheme yet *again*. I certainly don't think you're going to solve the problem you are trying to solve. The problem as stated is that people are not downloading and testing the test releases. Your solution to that problem is to make test releases look like real releases and maybe people will test them anyway. The solution should be to find a way to encourage people to download and test the test releases. Perhaps a "bug bounty" of some kind (it doesn't have to be money), or something similar, may prove to be a better motivator than trying to trick the userbase. It's not going to work. If you take the motivational approach, then it won't matter what you name the test releases, people will test them anyway. Several ideas right off the top of my head: - a "bug bounty" as I mentioned above. - a volunteer army of people, similar to the "kernel janitors", whose job is to do QA for the kernel. --Russell -- Russell Miller - [EMAIL PROTECTED] - Agoura, CA - 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: RFD: Kernel release numbering
On Wednesday 02 March 2005 17:23, Nick Piggin wrote: > Then your above becomes: > 2.6.x-rc: bugfixes only > 2.6.x-pre: bugfixes and features > > And then that doesn't confuse end users either. > Speaking as an "ordinary" end user (there's nothing ordinary about me) I think the idea of even/odd releases is silly. This accomplishes the same goals, and is less confusing all told. Linus's plan will work well for about... two releases, then people will wise up and stop testing the odd releases. I know that's what I'll probably end up doing. --Russell -- Russell Miller - [EMAIL PROTECTED] - Agoura, CA - 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: RFD: Kernel release numbering
On Wednesday 02 March 2005 17:23, Nick Piggin wrote: Then your above becomes: 2.6.x-rc: bugfixes only 2.6.x-pre: bugfixes and features And then that doesn't confuse end users either. Speaking as an ordinary end user (there's nothing ordinary about me) I think the idea of even/odd releases is silly. This accomplishes the same goals, and is less confusing all told. Linus's plan will work well for about... two releases, then people will wise up and stop testing the odd releases. I know that's what I'll probably end up doing. --Russell -- Russell Miller - [EMAIL PROTECTED] - Agoura, CA - 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: RFD: Kernel release numbering
On Wednesday 02 March 2005 19:37, Linus Torvalds wrote: That's the whole point here, at least to me. I want to have people test things out, but it doesn't matter how many -rc kernels I'd do, it just won't happen. It's not a real release. In contrast, making it a real release, and making it clear that it's a release in its own right, might actually get people to use it. Might. Maybe. Linus, I respect all of the work you have done on the Linux kernels over the years, and I have been an avid user of Linux almost since its inception (when I could get it to work with the hardware, at least in the early days ;-) And the fact that my contributions to the kernel are almost nonexistent probbly means you won't pay attention to a word I say anyway :-) that's alright, I'm going to say it and you can listen if you want. My respect for your accomplishments is why it pains me a great deal to have to tell you that I think you're wrong. I agree with the first part of your mail that I quoted above. Indeed, the -rc releases are not a real release, and therefore people aren't going to test it. What you are missing is that if you use the method you have proposed. odd numberered kernels will stop being a real release as well to a great deal of users. I don't think you will actually gain anything here except for just changing the kernel naming scheme yet *again*. I certainly don't think you're going to solve the problem you are trying to solve. The problem as stated is that people are not downloading and testing the test releases. Your solution to that problem is to make test releases look like real releases and maybe people will test them anyway. The solution should be to find a way to encourage people to download and test the test releases. Perhaps a bug bounty of some kind (it doesn't have to be money), or something similar, may prove to be a better motivator than trying to trick the userbase. It's not going to work. If you take the motivational approach, then it won't matter what you name the test releases, people will test them anyway. Several ideas right off the top of my head: - a bug bounty as I mentioned above. - a volunteer army of people, similar to the kernel janitors, whose job is to do QA for the kernel. --Russell -- Russell Miller - [EMAIL PROTECTED] - Agoura, CA - 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: RFD: Kernel release numbering
On Wednesday 02 March 2005 20:58, David S. Miller wrote: That's one of the major things the -rc's don't get. Maybe it gets a reference in lwn.net's weekly kernel article, but mostly kernel geeks read those and that's not who we want testing -rc's (such geeks already are doing so). How do you know that they won't stop the announcements if this change is made? --Russell -- Russell Miller - [EMAIL PROTECTED] - Agoura, CA - 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: [BK] upgrade will be needed
On Monday 14 February 2005 09:14, Marcin Dalecki wrote: > Give me a break! > Did may the idea perhaps occur to you that maybe the above wish list is: > > 1. Utterly immoral. > 2. Something you are by no ways entitled to have. > > If you want to be compensated for BK then put a price tag on it. > So what are you now trying to do is basically to use peoples wish to > contribute to > free software as a measure to prohibiting them from competing with your > commercial endeavor... that simply plain isn't fair play. > It is certainly Larry's choice to license his software any way he chooses. It is my choice whether or not to use it. BK will never pollute my machine as long as simply using it will restrict me from any other development or programming activity. I can understand it if the source code is made available. If it's just a binary... this is going way too far. --Russell -- Russell Miller - [EMAIL PROTECTED] - Agoura, CA - 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: [BK] upgrade will be needed
On Monday 14 February 2005 09:14, Marcin Dalecki wrote: Give me a break! Did may the idea perhaps occur to you that maybe the above wish list is: 1. Utterly immoral. 2. Something you are by no ways entitled to have. If you want to be compensated for BK then put a price tag on it. So what are you now trying to do is basically to use peoples wish to contribute to free software as a measure to prohibiting them from competing with your commercial endeavor... that simply plain isn't fair play. It is certainly Larry's choice to license his software any way he chooses. It is my choice whether or not to use it. BK will never pollute my machine as long as simply using it will restrict me from any other development or programming activity. I can understand it if the source code is made available. If it's just a binary... this is going way too far. --Russell -- Russell Miller - [EMAIL PROTECTED] - Agoura, CA - 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/
