Re: [2.6 patch] remove smbfs
On Wed, 30 Jan 2008 19:30:55 -0600 "Steve French" <[EMAIL PROTECTED]> wrote: > On Jan 30, 2008 7:13 PM, Jeff Layton <[EMAIL PROTECTED]> wrote: > > On Thu, 31 Jan 2008 02:47:17 +0200 > > > > > > > In addition, cifs cannot completely replace smbfs atm. > > > > > > > Even todays sold NAS-boxes (often running anchient > > > > > > > samba-2.x.x) work only with smbfs on the client side. > I am not convinced that this (mounting to older servers) would be a > problem with the proper mount options but it is more intuitive for > smbfs for some of the lanman servers. I do want to make sure that we > don't make it too easy to mount with insecure lanman (ie due to > downgrade attacks) without the user at least doing that (specify weak > lanman security explicitly). Today the user has to explicitly specify > sec=lanman which is confusing but at least makes explicit the weaker > security. > > There are four common issues with mounting to these very old servers: > 1) remembering to mount specifying lanman security (sec=lanman) I think it'd be nice to add an alias called oldsmb or similar for that option in mount.cifs. It should only be needed for old win9x servers. signature.asc Description: PGP signature
Re: questions on NAPI processing latency and dropped network packets
On Tue, 15 Jan 2008 08:47:07 -0600 "Chris Friesen" <[EMAIL PROTECTED]> wrote: > Jarek Poplawski wrote: > > > IMHO, checking this with a current stable, which probably you are going > > to do some day, anyway, should be 100% acceptable: giving some input to > > netdev, while still working for yourself. > > While I would love to do this, it's not that simple. > > Some of our hardware is not supported on mainline, so we need per-kernel > version patches to even bring up the blade. The blades netboot via a > jumbo-frame network, so kernel extensions are needed to handle setting > the MTU before mounting the rootfs. Why? Can't you use a small initramfs to set it up? > The blade in question uses CKRM > which doesn't exist for newer kernels so the problem may simply be > hidden by scheduling differences. Current spiritual successor is Ingo's realtime patchset I guess. > The userspace application uses other > kernel features that are not in mainline (and likely some of them won't > ever be in mainline--I know because I've tried). What would these be? Some proc or sysfs files that were removed or renamed? Maybe they can be worked around w/o changing the application at all, or very minor changes. Also, be sure to check if there are pauses with other CPU hogs. > Basically, the number of changes required for our environment makes it > difficult to just boot up the latest kernel. Yes, adding an initramfs is non-trivial (some busybox + shell scripting), but not all that hard either. And maintaining one is easier than patching the kernel. (usually 0 maintenance, maybe minor fixes sometimes) signature.asc Description: PGP signature
Re: questions on NAPI processing latency and dropped network packets
On Tue, 15 Jan 2008 08:47:07 -0600 Chris Friesen [EMAIL PROTECTED] wrote: Jarek Poplawski wrote: IMHO, checking this with a current stable, which probably you are going to do some day, anyway, should be 100% acceptable: giving some input to netdev, while still working for yourself. While I would love to do this, it's not that simple. Some of our hardware is not supported on mainline, so we need per-kernel version patches to even bring up the blade. The blades netboot via a jumbo-frame network, so kernel extensions are needed to handle setting the MTU before mounting the rootfs. Why? Can't you use a small initramfs to set it up? The blade in question uses CKRM which doesn't exist for newer kernels so the problem may simply be hidden by scheduling differences. Current spiritual successor is Ingo's realtime patchset I guess. The userspace application uses other kernel features that are not in mainline (and likely some of them won't ever be in mainline--I know because I've tried). What would these be? Some proc or sysfs files that were removed or renamed? Maybe they can be worked around w/o changing the application at all, or very minor changes. Also, be sure to check if there are pauses with other CPU hogs. Basically, the number of changes required for our environment makes it difficult to just boot up the latest kernel. Yes, adding an initramfs is non-trivial (some busybox + shell scripting), but not all that hard either. And maintaining one is easier than patching the kernel. (usually 0 maintenance, maybe minor fixes sometimes) signature.asc Description: PGP signature
Re: Trailing periods in kernel messages
On Sat, 22 Dec 2007 15:04:16 +0100 Benny Amorsen <[EMAIL PROTECTED]> wrote: > It is a bit of a mystery why the kernel is ordering me to initialize > the current offset of xfs_file_readdir though. I don't know how to do > that, so I guess it's lucky that I don't use XFS. Who knows what would > happen if I didn't correctly initialize xfs_file_readdir. I thinks it's not the kernel ordering you, it's the developer ordering the kernel to initialize that variable - presumably, because when it didn't do that, things broke. signature.asc Description: PGP signature
Re: Trailing periods in kernel messages
On Sat, 22 Dec 2007 15:04:16 +0100 Benny Amorsen [EMAIL PROTECTED] wrote: It is a bit of a mystery why the kernel is ordering me to initialize the current offset of xfs_file_readdir though. I don't know how to do that, so I guess it's lucky that I don't use XFS. Who knows what would happen if I didn't correctly initialize xfs_file_readdir. I thinks it's not the kernel ordering you, it's the developer ordering the kernel to initialize that variable - presumably, because when it didn't do that, things broke. signature.asc Description: PGP signature
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
On Wed, 19 Dec 2007 21:11:11 +0900 Tetsuo Handa <[EMAIL PROTECTED]> wrote: > Hello. > > Radoslaw Szkodzinski (AstralStorm) wrote: > > Actually, who needs to create device nodes? Just prohibit everyone from > > creating them, except "installer" and "udev" personality. > > This means removing CAP_MKNOD on a global scale. > > What happens if the root tampers udev's configuration file? > The udev will create inappropriate (i.e. filename with unexpected attributes) > device nodes, won't it? Yes. But root doesn't need access to these files, at least not usually. Create a separate user for editing config files - much lower probability of breakage. Remove almost all capabilities from root and profit. > After all, revoking CAP_MKNOD is not enough for guaranteeing > filename and its attributes. > > This filesystem is designed to guarantee filename and its attributes, > but this filesystem has additional access control capability. > You can forbid mknod/unlink /dev/null if you want nobody to do so. > You can forbid chmod/chown /dev/null if you want nobody to do so. You can forbid all operations on /dev (except udev) with an ACL. So, what is the need for this filesystem? signature.asc Description: PGP signature
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
On Wed, 19 Dec 2007 21:11:11 +0900 Tetsuo Handa [EMAIL PROTECTED] wrote: Hello. Radoslaw Szkodzinski (AstralStorm) wrote: Actually, who needs to create device nodes? Just prohibit everyone from creating them, except installer and udev personality. This means removing CAP_MKNOD on a global scale. What happens if the root tampers udev's configuration file? The udev will create inappropriate (i.e. filename with unexpected attributes) device nodes, won't it? Yes. But root doesn't need access to these files, at least not usually. Create a separate user for editing config files - much lower probability of breakage. Remove almost all capabilities from root and profit. After all, revoking CAP_MKNOD is not enough for guaranteeing filename and its attributes. This filesystem is designed to guarantee filename and its attributes, but this filesystem has additional access control capability. You can forbid mknod/unlink /dev/null if you want nobody to do so. You can forbid chmod/chown /dev/null if you want nobody to do so. You can forbid all operations on /dev (except udev) with an ACL. So, what is the need for this filesystem? signature.asc Description: PGP signature
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
On Mon, 17 Dec 2007 16:30:54 +1030 David Newall <[EMAIL PROTECTED]> wrote: > Tetsuo Handa wrote: > > If Bob is malicious and creates /dev/sda1 with block-8-2 attribute [...] > > Bob can't do that. Only root can. Not even root can, if you remove him the capability. Only udev can. (which possibly doesn't have to run as root, given correct capability set?) Of course root may be able to change the configuration of udev to create device nodes of his liking if you allow that... signature.asc Description: PGP signature
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
On Mon, 17 Dec 2007 16:05:31 +0300 Al Boldi <[EMAIL PROTECTED]> wrote: > Indan Zupancic wrote: > > On Mon, December 17, 2007 01:40, Tetsuo Handa wrote: > > I think you can better spend your time on read-only bind mounts. > > That would be too coarse. > Actually, who needs to create device nodes? Just prohibit everyone from creating them, except "installer" and "udev" personality. This means removing CAP_MKNOD on a global scale. (OTOH, both don't need CAP_SYS_ADMIN. Maybe udev needs CAP_SYS_MODULE...) Now, stopping people from faking hotplug events is totally another story. Is that currently possible? signature.asc Description: PGP signature
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
On Mon, 17 Dec 2007 16:05:31 +0300 Al Boldi [EMAIL PROTECTED] wrote: Indan Zupancic wrote: On Mon, December 17, 2007 01:40, Tetsuo Handa wrote: I think you can better spend your time on read-only bind mounts. That would be too coarse. Actually, who needs to create device nodes? Just prohibit everyone from creating them, except installer and udev personality. This means removing CAP_MKNOD on a global scale. (OTOH, both don't need CAP_SYS_ADMIN. Maybe udev needs CAP_SYS_MODULE...) Now, stopping people from faking hotplug events is totally another story. Is that currently possible? signature.asc Description: PGP signature
Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.
On Mon, 17 Dec 2007 16:30:54 +1030 David Newall [EMAIL PROTECTED] wrote: Tetsuo Handa wrote: If Bob is malicious and creates /dev/sda1 with block-8-2 attribute [...] Bob can't do that. Only root can. Not even root can, if you remove him the capability. Only udev can. (which possibly doesn't have to run as root, given correct capability set?) Of course root may be able to change the configuration of udev to create device nodes of his liking if you allow that... signature.asc Description: PGP signature
Re: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks
On Mon, 3 Dec 2007 14:29:56 +0100 > * Andi Kleen <[EMAIL PROTECTED]> wrote: > > > > feedback about an impending catastrophy has been duly noted > > > > The point was less about an impending catastrophe, but more of a > > timebomb ticking until the next widely used release. I think I know why Andi is so much against backtraces: he has some log filter listening on netconsole mailing him with suspicious log messages. Apparently, that log filter is much too stupid to discern an OOPS or OOM from softlockup and other informative backtraces even when given a clear hint what it is. Or maybe he's just underestimating user's ability to read. ;) signature.asc Description: PGP signature
Re: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks
On Mon, 3 Dec 2007 10:55:01 +0100 Andi Kleen <[EMAIL PROTECTED]> wrote: > On Sun, Dec 02, 2007 at 04:59:13PM -0800, Arjan van de Ven wrote: > > On Mon, 3 Dec 2007 01:07:41 +0100 > > Andi Kleen <[EMAIL PROTECTED]> wrote: > > > > > This patch will likely work against that by breaking error paths. > > > > it won't break error paths, it will at most put a warning in the log. > > It doesn't kill or otherwise damage the system or process. > > From the user perspective a kernel randomly throwing backtraces is > a broken kernel. Throwing in my 2c: Kernel waiting 2 minutes on TASK_UNINTERRUPTIBLE is certainly broken. I wouldn't wait that long for the system to become responsive, I yanked the power cord already. Hm, that's already detected with sleep_uninterruptible logic. A task that's not killable for more than 2 minutes is broken still, but less so. > > > > This patch is a step in the right direction there, by quite a > > > > lot. > > > > > > > > I really don't understand what your objection is to this patch... > > > > is it that an enterprise distro can't ship with it on? (Which is > > > > fine btw) > > > > > > Any distribution aimed at end users cannot ship with it on. > > > > That's a pretty bold statement; assuming that the TASK_KILLABLE patch > > is in, I don't see the problem. > > iirc TASK_KILLABLE fixed NFS only. While that's a good thing there are > unfortunately a lot more subsystems that would need the same treatment. Yes, that's exactly why the patch is needed - to find the bugs and fix them. Otherwise you'll have problems finding some places to convert to TASK_KILLABLE. CIFS and similar have to be fixed - it tends to lock the app using it, in unkillable state. > > > Also in general I have my doubts that the false positive:real bug > > > ratio of this warning is well balanced. > > > > I'll just have to disagree with you then; but both of us are making > > wild guesses. Only one way to get the real false positive percentage. > > Yes let's break things first instead of looking at the implications closely. Throwing _rare_ stack traces is not breakage. 120s task_uninterruptible in the usual case (no errors) is already broken - there are no sane loads that can invoke that IMO. A stack trace on x subsystem error is not that bad, especially as these are limited to 10 per session. Disclaimer: I am not a kernel developer, just a user. signature.asc Description: PGP signature
Re: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks
On Mon, 3 Dec 2007 10:55:01 +0100 Andi Kleen [EMAIL PROTECTED] wrote: On Sun, Dec 02, 2007 at 04:59:13PM -0800, Arjan van de Ven wrote: On Mon, 3 Dec 2007 01:07:41 +0100 Andi Kleen [EMAIL PROTECTED] wrote: This patch will likely work against that by breaking error paths. it won't break error paths, it will at most put a warning in the log. It doesn't kill or otherwise damage the system or process. From the user perspective a kernel randomly throwing backtraces is a broken kernel. Throwing in my 2c: Kernel waiting 2 minutes on TASK_UNINTERRUPTIBLE is certainly broken. I wouldn't wait that long for the system to become responsive, I yanked the power cord already. Hm, that's already detected with sleep_uninterruptible logic. A task that's not killable for more than 2 minutes is broken still, but less so. This patch is a step in the right direction there, by quite a lot. I really don't understand what your objection is to this patch... is it that an enterprise distro can't ship with it on? (Which is fine btw) Any distribution aimed at end users cannot ship with it on. That's a pretty bold statement; assuming that the TASK_KILLABLE patch is in, I don't see the problem. iirc TASK_KILLABLE fixed NFS only. While that's a good thing there are unfortunately a lot more subsystems that would need the same treatment. Yes, that's exactly why the patch is needed - to find the bugs and fix them. Otherwise you'll have problems finding some places to convert to TASK_KILLABLE. CIFS and similar have to be fixed - it tends to lock the app using it, in unkillable state. Also in general I have my doubts that the false positive:real bug ratio of this warning is well balanced. I'll just have to disagree with you then; but both of us are making wild guesses. Only one way to get the real false positive percentage. Yes let's break things first instead of looking at the implications closely. Throwing _rare_ stack traces is not breakage. 120s task_uninterruptible in the usual case (no errors) is already broken - there are no sane loads that can invoke that IMO. A stack trace on x subsystem error is not that bad, especially as these are limited to 10 per session. Disclaimer: I am not a kernel developer, just a user. signature.asc Description: PGP signature
Re: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks
On Mon, 3 Dec 2007 14:29:56 +0100 * Andi Kleen [EMAIL PROTECTED] wrote: feedback about an impending catastrophy has been duly noted The point was less about an impending catastrophe, but more of a timebomb ticking until the next widely used release. I think I know why Andi is so much against backtraces: he has some log filter listening on netconsole mailing him with suspicious log messages. Apparently, that log filter is much too stupid to discern an OOPS or OOM from softlockup and other informative backtraces even when given a clear hint what it is. Or maybe he's just underestimating user's ability to read. ;) signature.asc Description: PGP signature
Re: Is it possible to give the user the option to cancel forkbombs?
On Sat, 17 Nov 2007 09:55:01 -0800 Dane Mutters <[EMAIL PROTECTED]> wrote: > I don't know if this is at all feasible, but is it possible to have a > mechanism that would detect a fork bomb in progress and either stop the > fork, or allow the user to cancel the operation? For example, are there > any legitimate processes (i.e. ones that really need to fork like crazy) > that would need to generate 200+ processes in less than 1 second? > > (Note: I'm not a programmer; I'm just throwing out the idea.) > If the parent PID of the new task is exported through TASKSTATS, you can do it already in userspace. If not, that data should be exported. Then you could write a root daemon using netlink, set it to RT priority and create an inheritable counter in it to thwart binary forking. The counter would be cleared every x seconds. No need to do it in the kernel. signature.asc Description: PGP signature
Re: Is it possible to give the user the option to cancel forkbombs?
On Sat, 17 Nov 2007 09:55:01 -0800 Dane Mutters [EMAIL PROTECTED] wrote: I don't know if this is at all feasible, but is it possible to have a mechanism that would detect a fork bomb in progress and either stop the fork, or allow the user to cancel the operation? For example, are there any legitimate processes (i.e. ones that really need to fork like crazy) that would need to generate 200+ processes in less than 1 second? (Note: I'm not a programmer; I'm just throwing out the idea.) If the parent PID of the new task is exported through TASKSTATS, you can do it already in userspace. If not, that data should be exported. Then you could write a root daemon using netlink, set it to RT priority and create an inheritable counter in it to thwart binary forking. The counter would be cleared every x seconds. No need to do it in the kernel. signature.asc Description: PGP signature
Re: Possibility to adjust the only-root-can-bind-to-port-under-1024 limit
On Tue, 20 Nov 2007 17:09:35 +0100 Mikael Ståldal <[EMAIL PROTECTED]> wrote: > Hello. > > > The proper way to enable port <= 1024 binding support is adding > > CAP_NET_BIND_SERVICE > > to the process capability set, e.g. by using file-system capabilities. > > Is file-system capabilites part of the stable official Linux kernel? From > which version? > How do I use it? > They were recently added in 2.6.24-rc1. (mostly commit b53767719b6cd8789392ea3e7e2eb7b8906898f0) The patch should be easy to backport, I've seen it in various distro kernels. According to the commit, documentation is at http://www.friedhoff.org/fscaps.html Some programs already have capability support - they drop all permissions they don't need. signature.asc Description: PGP signature
Re: Possibility to adjust the only-root-can-bind-to-port-under-1024 limit
On Tue, 20 Nov 2007 11:14:59 +0100 Mikael Ståldal <[EMAIL PROTECTED]> wrote: > In Linux you have to be root in order to listen to TCP or UDP ports below > 1024 (the > well-known ports). As far as I know, this limit is hardcoded in the kernel. > > In some cases, this limit do more harm than good, so it would be nice to be > able to adjust it. The proper way to enable port <= 1024 binding support is adding CAP_NET_BIND_SERVICE to the process capability set, e.g. by using file-system capabilities. signature.asc Description: PGP signature
Re: Possibility to adjust the only-root-can-bind-to-port-under-1024 limit
On Tue, 20 Nov 2007 11:14:59 +0100 Mikael Ståldal [EMAIL PROTECTED] wrote: In Linux you have to be root in order to listen to TCP or UDP ports below 1024 (the well-known ports). As far as I know, this limit is hardcoded in the kernel. In some cases, this limit do more harm than good, so it would be nice to be able to adjust it. The proper way to enable port = 1024 binding support is adding CAP_NET_BIND_SERVICE to the process capability set, e.g. by using file-system capabilities. signature.asc Description: PGP signature
Re: Possibility to adjust the only-root-can-bind-to-port-under-1024 limit
On Tue, 20 Nov 2007 17:09:35 +0100 Mikael Ståldal [EMAIL PROTECTED] wrote: Hello. The proper way to enable port = 1024 binding support is adding CAP_NET_BIND_SERVICE to the process capability set, e.g. by using file-system capabilities. Is file-system capabilites part of the stable official Linux kernel? From which version? How do I use it? They were recently added in 2.6.24-rc1. (mostly commit b53767719b6cd8789392ea3e7e2eb7b8906898f0) The patch should be easy to backport, I've seen it in various distro kernels. According to the commit, documentation is at http://www.friedhoff.org/fscaps.html Some programs already have capability support - they drop all permissions they don't need. signature.asc Description: PGP signature
Re: [poll] Is the megafreeze development model broken?
On Mon, 12 Nov 2007 17:53:06 + (UTC) Tuomo Valkonen <[EMAIL PROTECTED]> wrote: > The complement of "open source" is not closed source, or at least > "source not available". (And I doubt it's even illegal to look at > source you have somehow got.) It includes so-called license-free > or license-less software [1] as well -- something I'm likely to do > with any of my future work, if I release the source at all. The only problem with djb's scheme is that you cannot mirror the software unless given permission from the author. No, not even unmodified source. And in some (weird) parts of the world, all rights are reserved by default. Not just distribution rights, also use rights. So you have to spell it out that you allow people to use the software unconditionally. There's no need to disclaim warranty if you don't expect to ever be sued. (anyway, it's not sold, so most warranty rights don't apply) Disclaimer: IANAL. > It's been a constant downfall ever since I started using Linux in '95 > or so. None of the gripes I had then have been fixed (the bloatware > known as the X server is still allowed to hang the system), and many > other things have been turned into crap, largely due to world domination > plans. (See the "idiot box Linux" link in one of the recent posts.) Everybody knows the story of X server development model, which has been very ineffective until recent xorg-x11 developments. It's just been 3 releases (7.0 and 7.1 count as one) since X.org took over. Cut it some slack just yet, please. Certain commercial X servers are nice and lightweight. Go buy a licence if you hate X.org distribution. Oh, it doesn't have the drivers you need? Tough luck. Pay your hardware developer and/or the company. Any system that doesn't have the same user base as Windows or enough money to bribe major hardware players will suffer the same problem. (Apple can pay some for drivers) BTW, why don't we see graphic systems other than X in the FOSS market? All such projects I can recall failed: Y-Windows, Fresco... Only Apple had enough manpower to implement its own replacement (Quartz), and they were in a better place: they were writing a system from scratch, with almost no concerns about backwards compatibility. So, in order to start an X replacement, you have to write an operating system around it... > Indeed, Microsoft is offering the only alternative to the suffocating > monoculturist hegemony promoted by the major FOSS projects. (OS X > is too much like Gnome.) Huh? It is the Microsoft that is the monoculture. They supply one true GUI with scarce documentation, a package of bundled software and libraries (including C library), one true media system (DirectShow) and one true configuration system - registry. And also an internet browser. Recently the suite has been expanded with .NET runtime. Guess what - these mostly (uhm...) work fine. The about only difference is that people (developers external to Microsoft) bundle software with the dependencies. I wonder why almost no distributions do that... You can install multiple versions of the same package... it requires moderate amount of work, nothing a medium-size distribution can't handle. (e.g. some Linux-From-Scratch installation methods and GoboLinux support multiple installations of the same package) Just some build system patches for certain software. Oh, you want to get everything with no work on your part? Go ask your vendor... that is, upstream. BTW, good flame bait. > [1]: http://www.thedjbway.org/license_free.html Footnotes have no place in emails. Theye are not books. signature.asc Description: PGP signature
Re: [poll] Is the megafreeze development model broken?
On Mon, 12 Nov 2007 17:53:06 + (UTC) Tuomo Valkonen [EMAIL PROTECTED] wrote: The complement of open source is not closed source, or at least source not available. (And I doubt it's even illegal to look at source you have somehow got.) It includes so-called license-free or license-less software [1] as well -- something I'm likely to do with any of my future work, if I release the source at all. The only problem with djb's scheme is that you cannot mirror the software unless given permission from the author. No, not even unmodified source. And in some (weird) parts of the world, all rights are reserved by default. Not just distribution rights, also use rights. So you have to spell it out that you allow people to use the software unconditionally. There's no need to disclaim warranty if you don't expect to ever be sued. (anyway, it's not sold, so most warranty rights don't apply) Disclaimer: IANAL. It's been a constant downfall ever since I started using Linux in '95 or so. None of the gripes I had then have been fixed (the bloatware known as the X server is still allowed to hang the system), and many other things have been turned into crap, largely due to world domination plans. (See the idiot box Linux link in one of the recent posts.) Everybody knows the story of X server development model, which has been very ineffective until recent xorg-x11 developments. It's just been 3 releases (7.0 and 7.1 count as one) since X.org took over. Cut it some slack just yet, please. Certain commercial X servers are nice and lightweight. Go buy a licence if you hate X.org distribution. Oh, it doesn't have the drivers you need? Tough luck. Pay your hardware developer and/or the company. Any system that doesn't have the same user base as Windows or enough money to bribe major hardware players will suffer the same problem. (Apple can pay some for drivers) BTW, why don't we see graphic systems other than X in the FOSS market? All such projects I can recall failed: Y-Windows, Fresco... Only Apple had enough manpower to implement its own replacement (Quartz), and they were in a better place: they were writing a system from scratch, with almost no concerns about backwards compatibility. So, in order to start an X replacement, you have to write an operating system around it... Indeed, Microsoft is offering the only alternative to the suffocating monoculturist hegemony promoted by the major FOSS projects. (OS X is too much like Gnome.) Huh? It is the Microsoft that is the monoculture. They supply one true GUI with scarce documentation, a package of bundled software and libraries (including C library), one true media system (DirectShow) and one true configuration system - registry. And also an internet browser. Recently the suite has been expanded with .NET runtime. Guess what - these mostly (uhm...) work fine. The about only difference is that people (developers external to Microsoft) bundle software with the dependencies. I wonder why almost no distributions do that... You can install multiple versions of the same package... it requires moderate amount of work, nothing a medium-size distribution can't handle. (e.g. some Linux-From-Scratch installation methods and GoboLinux support multiple installations of the same package) Just some build system patches for certain software. Oh, you want to get everything with no work on your part? Go ask your vendor... that is, upstream. BTW, good flame bait. [1]: http://www.thedjbway.org/license_free.html Footnotes have no place in emails. Theye are not books. signature.asc Description: PGP signature
Re: 2.6.13-rc3-mm3 question
On Thu, 28 Jul 2005 22:42:38 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote: > I'm surprised that you are that much concerned about compile errors when > using a kernel that might regularly exchange the contents of /dev/hda > and /dev/null . > These bugs don't happen too often in reality. Just please don't be malicious and add this kind of code deliberately. :) Every build breaker wastes my precious time to fix it. That's compulsive/obsessive in some way. ;) On the contrary, my "just break it" desktop is destined to have it's HDD contents overwritten once in a time. That's what these spare disks/computers are for, aren't they? All the data on that computer is volatile, all (not too frequent) backup is mostly made through the network and checked from the stable computer. If I really needed it very stable, I wouldn't test Reiser4 on it, less so a development kernel. That's why my stable machine uses latest release kernel, and only after it's broken in by at least a week. -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpexWeWujlaI.pgp Description: PGP signature
Re: 2.6.13-rc3-mm3 question
On Thu, 28 Jul 2005 10:55:51 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > It's there in the patch? Well, I didn't check there. Poor stupid me. > There are always glitches, I'm afraid. But there could be less build breakers at least. -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpByaxCZjMxI.pgp Description: PGP signature
2.6.13-rc3-mm3 question
I wonder which git version is linus.patch updating to, as it certainly isn't the mostly new git/hg tree (sans ALSA tree merge), as one patch didn't apply cleanly. (sched-consider-migration-thread-with-smp-nice.patch) It could be written as a comment, if that's not too hard to do. What about releasing a secret release just right before -mm in order to avoid problems like that MTRR problem? -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpxyt5wCmz3i.pgp Description: PGP signature
2.6.13-rc3-mm3 question
I wonder which git version is linus.patch updating to, as it certainly isn't the mostly new git/hg tree (sans ALSA tree merge), as one patch didn't apply cleanly. (sched-consider-migration-thread-with-smp-nice.patch) It could be written as a comment, if that's not too hard to do. What about releasing a secret release just right before -mm in order to avoid problems like that MTRR problem? -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpxyt5wCmz3i.pgp Description: PGP signature
Re: 2.6.13-rc3-mm3 question
On Thu, 28 Jul 2005 10:55:51 -0700 Andrew Morton [EMAIL PROTECTED] wrote: It's there in the patch? Well, I didn't check there. Poor stupid me. There are always glitches, I'm afraid. But there could be less build breakers at least. -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpByaxCZjMxI.pgp Description: PGP signature
Re: 2.6.13-rc3-mm3 question
On Thu, 28 Jul 2005 22:42:38 +0200 Adrian Bunk [EMAIL PROTECTED] wrote: I'm surprised that you are that much concerned about compile errors when using a kernel that might regularly exchange the contents of /dev/hda and /dev/null . These bugs don't happen too often in reality. Just please don't be malicious and add this kind of code deliberately. :) Every build breaker wastes my precious time to fix it. That's compulsive/obsessive in some way. ;) On the contrary, my just break it desktop is destined to have it's HDD contents overwritten once in a time. That's what these spare disks/computers are for, aren't they? All the data on that computer is volatile, all (not too frequent) backup is mostly made through the network and checked from the stable computer. If I really needed it very stable, I wouldn't test Reiser4 on it, less so a development kernel. That's why my stable machine uses latest release kernel, and only after it's broken in by at least a week. -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpexWeWujlaI.pgp Description: PGP signature
Re: MM kernels - how to keep on the bleeding edge?
On Tue, 26 Jul 2005 16:35:21 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > > I did? > Exactly, I did untar it and I already had a directory called patches. Of course cleaning it up took no time, as fortunately I had no patches with exactly the same name and no series file in the directory above, -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpcNiBSpWL7C.pgp Description: PGP signature
Re: MM kernels - how to keep on the bleeding edge?
On Tue, 26 Jul 2005 16:11:49 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > > All done - let me know if it needs anything else. > You got me with a tarball w/o a directory inside. Now I have to clean up the mess. Not the first time in life. I think I'll never learn. :) -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpPJmrxbwqBI.pgp Description: PGP signature
Re: MM kernels - how to keep on the bleeding edge?
On Tue, 26 Jul 2005 15:32:51 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > I spose I could emit a broken-out.tar.gz file occasionally (it'd be up to 5 > > times a day), > > OK, I did that. > Great! > The kernel.org propagation delay is a bit of a hassle. I could use > zip.com.au but I suspect they hate me enough already. > Right now the delay is about one hour. I can certainly live with that. -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpsdmlgqdZ2F.pgp Description: PGP signature
Re: MM kernels - how to keep on the bleeding edge?
On Tue, 26 Jul 2005 14:41:49 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > Michael Krufky <[EMAIL PROTECTED]> wrote: > > > > [ tracking mm stuff ] > > > > Sigh, sorry. It's hard. -mm is always in flux. I no longer send out the > `patch was dropped' message because it disturbs people. There were too many? Or you were receiving a lot of mail from particular developers with requests of explanation? :) > The mm-commits > list does not resend a patch when it is changed (other patches folded into > it, rejects fixed, changelog updated, rediffed, etc). This isn't so much a problem as the previous point. When there are rejects, it's easy (most of the time) to fix them by hand anyway as I pull the tree. > Sometimes I'll comment out a patch but not fully drop it. Now I can see that, I can diff the series. But if the change was large, the diff isn't very instructive. > I pull all the git trees at > least twice a day and that's not reflected on the mm-commits list either. > That's not a problem, I can pull them too. They're public. > You can always tell when a -mm release is coming by watching the shower of > stupid compile fixes emerging :( I do notice that using the RSS already, :) And the usual shower isn't as frequent and large nowadays as before. > > I spose I could emit a broken-out.tar.gz file occasionally (it'd be up to 5 > times a day), but there's no guarantee that it'll compile, let alone run. > I could also send a notification to mm-commits when I do so. Would that > help? > Really, it would. Especially if it contained an up-to-date series file. I'd be very grateful. (And would test and fix it up some more.) -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpwUvpoLjMQU.pgp Description: PGP signature
Re: MM kernels - how to keep on the bleeding edge?
On Tue, 26 Jul 2005 15:45:41 -0400 Michael Krufky <[EMAIL PROTECTED]> wrote: > I have filters set up so that my mailer puts all mm-commits messages > from the mailing list into a special "mm-commits" folder. Each time > Andrew releases an -mm kernel, I rename my "mm-commits" folder to > "mm-commits-%version%", such as "mm-commits-2.6.13-rc3-mm2" (I will > probably have to create a folder like this tomorrow, or in a few > hours/days ;-) ... Then I create a new "mm-commits" folder to hold all > new patches not yet in the latest -mm kernel. As of right now, my > current "mm-commits" mail folder has 153 patches in it, although I think > I may have lost a patch or two... The problem is detecting if or when the latest -mm got created. If I have to do it by hand, it becomes a major PITA. I could use RSS to do this, but some patches may still hit the wrong folder. What's more it would create unnecessary network load. There are sometimes only a few minutes between "patch in -mm1" and "patch in -mm2". -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpGaiSKulH6J.pgp Description: PGP signature
MM kernels - how to keep on the bleeding edge?
I've a question on how to keep in touch with all those patches going into mm patchset. Yes, I know of and am subscribed to mm-commits list, but it has a few shortcomings: a) It doesn't tell which patches went into the mainline. That's not necessary, as there's always git, but comparing on commit messages seems awkward and the contents aren't necessarily the same. Maybe AM has some algorithm to determine which patches went in and which, say, went in only in part? Or that he redoes all the patches against the newest Linus' tree? Anyway, I'd like to know what was the tree version at the time. b) It doesn't say which -mm version are they in. This is a real PITA, because I have to check patch list one after one to apply to the newest mm. A message consisting of: Subject: 2.6.x-mmy released Contains all patches up to: abc-fix.patch Is based on Linus' tree up to commit: xyzabc123 would be more than enough. This way it would be easy to update the latest patchset to the latest and (hopefully) greatest mailing list patch. As it is now, I have to do a search every time I blow up the tree. It would be much easier for me if there was a mercurial or git tree with mm patches available somewhere, but I can live with my mail reading script. (I'm not subscribed to the list at the time - my mailbox would blow up) -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpha6xwJWwph.pgp Description: PGP signature
MM kernels - how to keep on the bleeding edge?
I've a question on how to keep in touch with all those patches going into mm patchset. Yes, I know of and am subscribed to mm-commits list, but it has a few shortcomings: a) It doesn't tell which patches went into the mainline. That's not necessary, as there's always git, but comparing on commit messages seems awkward and the contents aren't necessarily the same. Maybe AM has some algorithm to determine which patches went in and which, say, went in only in part? Or that he redoes all the patches against the newest Linus' tree? Anyway, I'd like to know what was the tree version at the time. b) It doesn't say which -mm version are they in. This is a real PITA, because I have to check patch list one after one to apply to the newest mm. A message consisting of: Subject: 2.6.x-mmy released Contains all patches up to: abc-fix.patch Is based on Linus' tree up to commit: xyzabc123 would be more than enough. This way it would be easy to update the latest patchset to the latest and (hopefully) greatest mailing list patch. As it is now, I have to do a search every time I blow up the tree. It would be much easier for me if there was a mercurial or git tree with mm patches available somewhere, but I can live with my mail reading script. (I'm not subscribed to the list at the time - my mailbox would blow up) -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpha6xwJWwph.pgp Description: PGP signature
Re: MM kernels - how to keep on the bleeding edge?
On Tue, 26 Jul 2005 15:45:41 -0400 Michael Krufky [EMAIL PROTECTED] wrote: I have filters set up so that my mailer puts all mm-commits messages from the mailing list into a special mm-commits folder. Each time Andrew releases an -mm kernel, I rename my mm-commits folder to mm-commits-%version%, such as mm-commits-2.6.13-rc3-mm2 (I will probably have to create a folder like this tomorrow, or in a few hours/days ;-) ... Then I create a new mm-commits folder to hold all new patches not yet in the latest -mm kernel. As of right now, my current mm-commits mail folder has 153 patches in it, although I think I may have lost a patch or two... The problem is detecting if or when the latest -mm got created. If I have to do it by hand, it becomes a major PITA. I could use RSS to do this, but some patches may still hit the wrong folder. What's more it would create unnecessary network load. There are sometimes only a few minutes between patch in -mm1 and patch in -mm2. -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpGaiSKulH6J.pgp Description: PGP signature
Re: MM kernels - how to keep on the bleeding edge?
On Tue, 26 Jul 2005 14:41:49 -0700 Andrew Morton [EMAIL PROTECTED] wrote: Michael Krufky [EMAIL PROTECTED] wrote: [ tracking mm stuff ] Sigh, sorry. It's hard. -mm is always in flux. I no longer send out the `patch was dropped' message because it disturbs people. There were too many? Or you were receiving a lot of mail from particular developers with requests of explanation? :) The mm-commits list does not resend a patch when it is changed (other patches folded into it, rejects fixed, changelog updated, rediffed, etc). This isn't so much a problem as the previous point. When there are rejects, it's easy (most of the time) to fix them by hand anyway as I pull the tree. Sometimes I'll comment out a patch but not fully drop it. Now I can see that, I can diff the series. But if the change was large, the diff isn't very instructive. I pull all the git trees at least twice a day and that's not reflected on the mm-commits list either. That's not a problem, I can pull them too. They're public. You can always tell when a -mm release is coming by watching the shower of stupid compile fixes emerging :( I do notice that using the RSS already, :) And the usual shower isn't as frequent and large nowadays as before. I spose I could emit a broken-out.tar.gz file occasionally (it'd be up to 5 times a day), but there's no guarantee that it'll compile, let alone run. I could also send a notification to mm-commits when I do so. Would that help? Really, it would. Especially if it contained an up-to-date series file. I'd be very grateful. (And would test and fix it up some more.) -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpwUvpoLjMQU.pgp Description: PGP signature
Re: MM kernels - how to keep on the bleeding edge?
On Tue, 26 Jul 2005 15:32:51 -0700 Andrew Morton [EMAIL PROTECTED] wrote: Andrew Morton [EMAIL PROTECTED] wrote: I spose I could emit a broken-out.tar.gz file occasionally (it'd be up to 5 times a day), snip OK, I did that. Great! The kernel.org propagation delay is a bit of a hassle. I could use zip.com.au but I suspect they hate me enough already. Right now the delay is about one hour. I can certainly live with that. -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpsdmlgqdZ2F.pgp Description: PGP signature
Re: MM kernels - how to keep on the bleeding edge?
On Tue, 26 Jul 2005 16:11:49 -0700 Andrew Morton [EMAIL PROTECTED] wrote: All done - let me know if it needs anything else. You got me with a tarball w/o a directory inside. Now I have to clean up the mess. Not the first time in life. I think I'll never learn. :) -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpPJmrxbwqBI.pgp Description: PGP signature
Re: MM kernels - how to keep on the bleeding edge?
On Tue, 26 Jul 2005 16:35:21 -0700 Andrew Morton [EMAIL PROTECTED] wrote: I did? Exactly, I did untar it and I already had a directory called patches. Of course cleaning it up took no time, as fortunately I had no patches with exactly the same name and no series file in the directory above, -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpcNiBSpWL7C.pgp Description: PGP signature
Re: [ck] Re: 2.6.12-ck3
On Thu, 7 Jul 2005 23:30:34 +0200 Rudo Thomas <[EMAIL PROTECTED]> wrote: > Hi again. > > > Time seems to pass very fast with this kernel. > > dmesg output has not revealed anything extraordinary... > > Am I the only one who gets this strange behaviour? Kernel's notion of > time seems to be about 30 times faster than real time. > > I will gladly provide any information that will help sorting this > problem out. > I've seen something like this with some VIA mainboards. But that was happening on all kernels. The problem was broken TSC I think. The solution was to enable HPET and/or enable ACPI PM Timer. -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpVqvtRPfcHf.pgp Description: PGP signature
Re: [ck] Re: 2.6.12-ck3
On Thu, 7 Jul 2005 23:30:34 +0200 Rudo Thomas [EMAIL PROTECTED] wrote: Hi again. Time seems to pass very fast with this kernel. dmesg output has not revealed anything extraordinary... Am I the only one who gets this strange behaviour? Kernel's notion of time seems to be about 30 times faster than real time. I will gladly provide any information that will help sorting this problem out. I've seen something like this with some VIA mainboards. But that was happening on all kernels. The problem was broken TSC I think. The solution was to enable HPET and/or enable ACPI PM Timer. -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpVqvtRPfcHf.pgp Description: PGP signature
