Andrew Morton <[email protected]> wrote:
>
>> (These buffers are there because reiserfs first reads that offset (in bytes)
>> with whatever current blocksize is, except they should have been invalidated of
>> course).
>> Even if invalidate_bdev() -> invalidate_inode_pages() have not cleaned
>> everything, truncate_inode_pages() should have done this.
>
> yup.
The person who had the problem is actually using the Debian tree which
carried over a patch from 2.4 that removed the truncate_inode_pages
call in set_blocksize. So I appologise for the noise.
However, may I ask what is preventing us from achieving the goal that
the page cache backed buffer heads can be resized without throwing away
the pages?
In particular, aside from the buffer_error() call, is there any problems
with not throwing the pages away upon a resize?
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Herbert Xu <[email protected]> wrote:
>
> Andrew Morton <[email protected]> wrote:
> >
> >> (These buffers are there because reiserfs first reads that offset (in bytes)
> >> with whatever current blocksize is, except they should have been invalidated of
> >> course).
> >> Even if invalidate_bdev() -> invalidate_inode_pages() have not cleaned
> >> everything, truncate_inode_pages() should have done this.
> >
> > yup.
>
> The person who had the problem is actually using the Debian tree which
> carried over a patch from 2.4 that removed the truncate_inode_pages
> call in set_blocksize. So I appologise for the noise.
aargh. I thought Debian's 2.6 kernels were unmodified. Are they carrying
any other changes?
> However, may I ask what is preventing us from achieving the goal that
> the page cache backed buffer heads can be resized without throwing away
> the pages?
That _should_ work. The pagecache pages should be in such a state that all
buffers are freeable and yes, we can leave the pagecache there. But this
could cause problems if the device was repartitioned in between, or if it
was hotswapped. I don't think we shoot down pagecache anywhere else for
this.
truncate_inode_pages() will unconditionally remove the pages from
pagecache: they're gone. So if some poorly behaved piece of code
(reiserfs's read_super_block()) holds a reference against a buffer, that
piece of code ends up owning the page - the VFS has lost interest in it.
This is almost always very bad - if truncate_inode_pages() against a
blockdev fails to cleanly remove all pages then it often means memory
leakage or data corruption. I would like to have a warning which detects
this case but I never got around to it.
On Sat, Nov 01, 2003 at 11:33:54PM -0800, Andrew Morton wrote:
>
> aargh. I thought Debian's 2.6 kernels were unmodified. Are they carrying
> any other changes?
Yes we are. You can find the changes in
http://http.us.debian.org/debian/pool/main/k/kernel-source-2.6.0-test9/
> That _should_ work. The pagecache pages should be in such a state that all
> buffers are freeable and yes, we can leave the pagecache there. But this
> could cause problems if the device was repartitioned in between, or if it
> was hotswapped. I don't think we shoot down pagecache anywhere else for
> this.
Yes, however it should be safe to stop set_blocksize from calling
truncate_inode_pages, right?
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Hello!
On Sat, Nov 01, 2003 at 11:33:54PM -0800, Andrew Morton wrote:
> > >> (These buffers are there because reiserfs first reads that offset (in bytes)
> > >> with whatever current blocksize is, except they should have been invalidated of
> > >> course).
> > >> Even if invalidate_bdev() -> invalidate_inode_pages() have not cleaned
> > >> everything, truncate_inode_pages() should have done this.
> > > yup.
> > The person who had the problem is actually using the Debian tree which
> > carried over a patch from 2.4 that removed the truncate_inode_pages
> > call in set_blocksize. So I appologise for the noise.
Sigh.
> truncate_inode_pages() will unconditionally remove the pages from
> pagecache: they're gone. So if some poorly behaved piece of code
> (reiserfs's read_super_block()) holds a reference against a buffer, that
> piece of code ends up owning the page - the VFS has lost interest in it.
Here's the patch against reiserfs in 2.6 (2.4 does not need it as this bit
of code is different and correct there).
===== fs/reiserfs/super.c 1.69 vs edited =====
--- 1.69/fs/reiserfs/super.c Tue Sep 23 07:16:25 2003
+++ edited/fs/reiserfs/super.c Sun Nov 2 11:11:36 2003
@@ -942,6 +942,7 @@
{
struct buffer_head * bh;
struct reiserfs_super_block * rs;
+ int fs_blocksize;
bh = sb_bread (s, offset / s->s_blocksize);
@@ -961,8 +962,9 @@
//
// ok, reiserfs signature (old or new) found in at the given offset
//
- sb_set_blocksize (s, sb_blocksize(rs));
+ fs_blocksize = sb_blocksize(rs);
brelse (bh);
+ sb_set_blocksize (s, fs_blocksize);
bh = sb_bread (s, offset / s->s_blocksize);
if (!bh) {
Bye,
Oleg
Herbert Xu <[email protected]> wrote:
>
> On Sat, Nov 01, 2003 at 11:33:54PM -0800, Andrew Morton wrote:
> >
> > aargh. I thought Debian's 2.6 kernels were unmodified. Are they carrying
> > any other changes?
>
> Yes we are. You can find the changes in
>
> http://http.us.debian.org/debian/pool/main/k/kernel-source-2.6.0-test9/
Where are the separated patches?
That's 170k of stuff you're sitting on. Is there any plan to get it synced
up?
> > That _should_ work. The pagecache pages should be in such a state that all
> > buffers are freeable and yes, we can leave the pagecache there. But this
> > could cause problems if the device was repartitioned in between, or if it
> > was hotswapped. I don't think we shoot down pagecache anywhere else for
> > this.
>
> Yes, however it should be safe to stop set_blocksize from calling
> truncate_inode_pages, right?
No, because _something_ has to rub out the wrong-sized buffer_heads. One
could add some new function which walks the pagecache and removes the
buffer_heads from the pages, leaving the pages there. There doesn't seem a
lot of point in it though?
On Sun, Nov 02, 2003 at 01:40:11AM -0800, Andrew Morton wrote:
>
> Where are the separated patches?
There are no separate patches. You can check the README.Debian file
for the details of the changes.
> That's 170k of stuff you're sitting on. Is there any plan to get it synced
> up?
I submit them as they come in. The bulk of the size comes from the
making IDE modules work which isn't right yet.
The rest of them which are suitable for general consumption have
been submitted previously. I will resend them later.
> No, because _something_ has to rub out the wrong-sized buffer_heads. One
> could add some new function which walks the pagecache and removes the
> buffer_heads from the pages, leaving the pages there. There doesn't seem a
> lot of point in it though?
Actually grow_dev_page will free the wrong-sized ones.
It seems that the only problem is that we don't check the size in
__find_get_block_slow(). So what about this patch?
The point of all this is to avoid unnecessary reads, and more importantly
preserve the contents of RAM disks when someone calls set_blocksize().
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Herbert Xu wrote:
>On Sat, Nov 01, 2003 at 11:33:54PM -0800, Andrew Morton wrote:
>
>
>>aargh. I thought Debian's 2.6 kernels were unmodified. Are they carrying
>>any other changes?
>>
>>
>
>Yes we are. You can find the changes in
>
>http://http.us.debian.org/debian/pool/main/k/kernel-source-2.6.0-test9/
>
>
>
>
Why are you guys modifying the official kernel? Are you seeking
advantage over the other distros or? This was one of the nice things
about debian, that it didn't have unofficial destabilizing stuff in the
kernel like the other distros.
--
Hans
Herbert Xu wrote:
>On Sun, Nov 02, 2003 at 01:40:11AM -0800, Andrew Morton wrote:
>
>
>>Where are the separated patches?
>>
>>
>
>There are no separate patches. You can check the README.Debian file
>for the details of the changes.
>
>
>
>>That's 170k of stuff you're sitting on. Is there any plan to get it synced
>>up?
>>
>>
>
>I submit them as they come in. The bulk of the size comes from the
>making IDE modules work which isn't right yet.
>
>The rest of them which are suitable for general consumption have
>been submitted previously. I will resend them later.
>
>
Why in the world do you guys do this? Andrew and Marcelo do a good job,
and I haven't heard much complaint about patches being ignored by them,
so follow the leader. If you have patches you need, send them to them.
--
Hans
On Sun, Nov 02, 2003 at 02:50:17PM +0300, Hans Reiser wrote:
>
> Why are you guys modifying the official kernel? Are you seeking
> advantage over the other distros or? This was one of the nice things
> about debian, that it didn't have unofficial destabilizing stuff in the
> kernel like the other distros.
I don't know where you got the idea that Debian used to distribute the
kernel as it is. Just like every other distribution, we have always
needed (mostly small) changes to the vanilla kernel.
We do send those changes suitable for general consumption to the
upstream maintainers. Whether they are accepted is an entirely
different question.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Sun, Nov 02, 2003 at 02:54:45PM +0300, Hans Reiser wrote:
>
> Why in the world do you guys do this? Andrew and Marcelo do a good job,
> and I haven't heard much complaint about patches being ignored by them,
> so follow the leader. If you have patches you need, send them to them.
Andrew and Marcelo do an excellent job. I have never said otherwise
nor attempted to infer that.
The reasons that we need patches are mostly the same as other distributions:
1. Our release schedule is different from the vanilla kernels.
When we release a kernel based on a vanilla release there may be bug
fixes that are going to be in the next vanilla release that we can
apply straight away.
2. Our goals are different from the vanilla kernel.
Some issues are not critical to the vanilla kernel, e.g., IDE modules
but are release-critical for us.
3. Licensing problems.
This is specific to Debian. For anything to be included in our release,
it has to pass the DFSG. The vanilla kernel does not have this
restriction so we may need to remove bits before it's suitable for us.
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Mon, 3 Nov 2003 08:09:42 +1100
Herbert Xu <[email protected]> wrote:
Forgive my comments unrelated to the primary topic, but I think additional
voices may do something good to your general idea of a distro.
> On Sun, Nov 02, 2003 at 02:54:45PM +0300, Hans Reiser wrote:
> >
> > Why in the world do you guys do this? Andrew and Marcelo do a good job,
> > and I haven't heard much complaint about patches being ignored by them,
> > so follow the leader. If you have patches you need, send them to them.
>
> Andrew and Marcelo do an excellent job. I have never said otherwise
> nor attempted to infer that.
>
> The reasons that we need patches are mostly the same as other distributions:
>
> 1. Our release schedule is different from the vanilla kernels.
>
> When we release a kernel based on a vanilla release there may be bug
> fixes that are going to be in the next vanilla release that we can
> apply straight away.
Release cycle of vanilla kernels has become short/acceptable again, so it
should be possible to pick one up inside your timeframe. And yes, there will
always be another bug, so if you go hunting for only the next bugfix, you will
probably be releasing never again.
> 2. Our goals are different from the vanilla kernel.
>
> Some issues are not critical to the vanilla kernel, e.g., IDE modules
> but are release-critical for us.
You are talking about an additional _feature_. Why don't you try to make it an
accepted and implemented feature in the vanilla kernels? Sure this may take a
bit more time, but the community wins as a whole. I cannot see the point in
_separation_ regarding GPL'ed software.
> 3. Licensing problems.
>
> This is specific to Debian. For anything to be included in our release,
> it has to pass the DFSG. The vanilla kernel does not have this
> restriction so we may need to remove bits before it's suitable for us.
Uh? Do you place licensing restrictions on a GPL'ed kernel??
I really send prayers for the day distros will stop building own kernels for
they only reduce the installed test base for kernels as a whole by splitting it
up in numerous kernel versions...
Regards,
Stephan
Stephan von Krawczynski wrote:
>
>
>I really send prayers for the day distros will stop building own kernels for
>they only reduce the installed test base for kernels as a whole by splitting it
>up in numerous kernel versions...
>
>Regards,
>Stephan
>
>
>
>
>
Amen. Since Debian is a not for profit organization, it really should
not be doing this.
--
Hans
> Stephan von Krawczynski wrote:
> >I really send prayers for the day distros will stop building own kernels
> >for
> >they only reduce the installed test base for kernels as a whole by
> >splitting it
> >up in numerous kernel versions...
On Tue, Nov 04, 2003 at 12:10:45AM -0800, Hans Reiser wrote:
> Amen. Since Debian is a not for profit organization, it really should
> not be doing this.
Ok guys, this has gotten pretty far OT.
Being a debian user since Dec 1998 (first and only distro), I might be able
to explain some things.
Debian is not trying to relicense any GPLed code, but it does have another
guide it follows as to what it will include in a Debian release; the DFSG -
Debian Free Software Guide.
Some licenses that are considered compatible with the GPL on LKML are not in
the DFSG. I believe the latest one is the GNU Documentation License, but
that's still being argued about...
I have been using official Debian packages for everything except for the
kernel. First because I wanted to test the -pre, -mm, -aa, and other
kernels, and second that I didn't like the vesafb that was turned on by
default.
I'd love to see the 'initrd on cramfs' patch merged into the vanilla kernel
though. :)
Now, let's try to get it back On Topic...
There was a bug in one of the released Debian kernels, and do you think this
hasn't happened with Redhat, SuSe, or Mandrake? Just because Debian is
completely OSS and maintained mostly by unpaid volunteers, that shouldn't keep
them from having a seperate tree like everyone else.
I'd like to see each vendor tree as small as possible. And Debian's may be
the smallest vendor tree AFAIK they haven't merged XFS into their 2.4 tree.
But think about this. Linus wants to see features have a large user base
before merging many outside kernel projects, and vendor kernels are one way
to show a project is popular.
It's bad enough that there are over 5 other distros based on Debian, and
only now are any of them contributing back to the installer, and maybe we
will get some hardware detection out of Knoppix!
So, has this bug been fixed? And if not, what other patches are needed to
test more?
Mike Fedyk wrote:
> Just because Debian is
>
>completely OSS and maintained mostly by unpaid volunteers, that shouldn't keep
>them from having a seperate tree like everyone else.
>
>
Yes it should. They have less fiscal motivation to horde software than
other distros, and a distro having it's own tree is a mild version of
software hording in which you don't do anything legally to stop others
from copying your code but you don't do the work necessary for them to
share in it either.
--
Hans
On Tue, 4 Nov 2003 13:03:10 -0800
Mike Fedyk <[email protected]> wrote:
> There was a bug in one of the released Debian kernels, and do you think this
> hasn't happened with Redhat, SuSe, or Mandrake? Just because Debian is
> completely OSS and maintained mostly by unpaid volunteers, that shouldn't
> keep them from having a seperate tree like everyone else.
Just to avoid a false impression: I am in no way against debian project nor do
I say there is anything specifically bad about it. I am generally disliking
distros' ideas of having _own_ kernels. Commercial companies like SuSE or Red
Hat may find arguments for that which are commercially backed, debian on the
other hand can hardly argue commercially. From the community point of view it
is just nonsense. It means more work and less useable feedback.
Bugs is distro kernels are (always) the sole fault of their respective
maintainers because they actively decided _not_ to follow the mainstream and
made bogus patches. Why waste the appreciated work of (unpaid) debian
volunteers in this area? There are tons of other work left with far more
relevance for users than bleeding edge kernel patches...
And if you really insist to pick up the tough pieces around kernel then find
out why 2.4.20 is the last stable netfilter implementation... for sure far more
relevant than loadable module ide code in 2.6.0-testX.
Regards,
Stephan
On Wed, Nov 05, 2003 at 12:49:56AM +0100, Stephan von Krawczynski wrote:
> On Tue, 4 Nov 2003 13:03:10 -0800
> Mike Fedyk <[email protected]> wrote:
>
> > There was a bug in one of the released Debian kernels, and do you think this
> > hasn't happened with Redhat, SuSe, or Mandrake? Just because Debian is
> > completely OSS and maintained mostly by unpaid volunteers, that shouldn't
> > keep them from having a seperate tree like everyone else.
>
> Just to avoid a false impression: I am in no way against debian project nor do
> I say there is anything specifically bad about it. I am generally disliking
> distros' ideas of having _own_ kernels. Commercial companies like SuSE or Red
> Hat may find arguments for that which are commercially backed, debian on the
> other hand can hardly argue commercially. From the community point of view it
> is just nonsense. It means more work and less useable feedback.
> Bugs is distro kernels are (always) the sole fault of their respective
> maintainers because they actively decided _not_ to follow the mainstream and
> made bogus patches. Why waste the appreciated work of (unpaid) debian
> volunteers in this area? There are tons of other work left with far more
> relevance for users than bleeding edge kernel patches...
I agree with you for the most part.
Herbert did say he submitted patches for the parts that were ready. He
didn't say if he was working with Bart and Alan on the IDE changes though.
I haven't seen any messages from him on lkml with "patch" in the subject,
but that doesn't mean he's not working with the maintianers.
Herb, what do you have to say on this?
Hi!
> > There was a bug in one of the released Debian kernels, and do you think this
> > hasn't happened with Redhat, SuSe, or Mandrake? Just because Debian is
> > completely OSS and maintained mostly by unpaid volunteers, that shouldn't
> > keep them from having a seperate tree like everyone else.
>
> Just to avoid a false impression: I am in no way against debian project nor do
> I say there is anything specifically bad about it. I am generally disliking
> distros' ideas of having _own_ kernels. Commercial companies like SuSE or Red
> Hat may find arguments for that which are commercially backed, debian on the
> other hand can hardly argue commercially. From the community point of view it
> is just nonsense. It means more work and less useable feedback.
> Bugs is distro kernels are (always) the sole fault of their respective
> maintainers because they actively decided _not_ to follow the mainstream and
> made bogus patches. Why waste the appreciated work of (unpaid) debian
> volunteers in this area? There are tons of other work left with far more
> relevance for users than bleeding edge kernel patches...
Debian is distibution; distributions are _expected_ to fix bugs (etc)
in their packages.
If distribution had all packages unmodified, it would be useless...
So I'd expect all distros to have at least some changes in their
kernel... the same way I expect distros to have some patches in
midnight commander etc.
Of course it is good to keep the .diff as small as possible.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
On Sun, 16 Nov 2003 14:05:58 +0100
Pavel Machek <[email protected]> wrote:
> Hi!
> [...]
> > Just to avoid a false impression: I am in no way against debian project nor
> > do I say there is anything specifically bad about it. I am generally
> > disliking distros' ideas of having _own_ kernels. Commercial companies like
> > SuSE or Red Hat may find arguments for that which are commercially backed,
> > debian on the other hand can hardly argue commercially. From the community
> > point of view it is just nonsense. It means more work and less useable
> > feedback. Bugs is distro kernels are (always) the sole fault of their
> > respective maintainers because they actively decided _not_ to follow the
> > mainstream and made bogus patches. Why waste the appreciated work of
> > (unpaid) debian volunteers in this area? There are tons of other work left
> > with far more relevance for users than bleeding edge kernel patches...
>
>
> Debian is distibution; distributions are _expected_ to fix bugs (etc)
> in their packages.
I am just of the opposite opinion. It is a project maintainers' job to fix
bugs. A distributions' job is to _distribute_ packages in its pure sense.
Obviously people creating a distribution run across bugs while checking out the
projects to pack into their distro. So I very well agree they should do
_something_ about it, BUT this "something" is _not_ creating more or less
useful patches for their (and their customers) use, but get in contact with the
project maintainer and hand them the patches, look for their approval and
_then_ move the project into their distro. There is no sense in creating a
debian patched pppd, a SuSE patched pppd and a RH-patched pppd, altogether
different from the projects basic pppd. (This is not a real example, but only a
clarification of what I'd say is _the wrong way_ (tm))
> If distribution had all packages unmodified, it would be useless...
Just contrary I'd state that this would be the "perfect world", because this
would mean all projects are in perfect shape and all patches have gone to the
respective maintainers.
> So I'd expect all distros to have at least some changes in their
> kernel... the same way I expect distros to have some patches in
> midnight commander etc.
So you say midnight commanders' maintainer is an a**hole, or what?
If you think some project needs patches, then please talk to its maintainer (if
any), or get involved and become its maintainer...
I do think though, that there should be something in between, namely a place
where projects are hosted that (currently) have no maintainer, but where one
can send patches that are needed for some reason. This is a bit of a political
question, maybe OSDL can be such a place. Whatever the place is, it should be
independent to a degree.
> Of course it is good to keep the .diff as small as possible.
diffsize small is wanted.
diffsize zero is unwanted.
What kind of a logic is that?
Forgive me Pavel, that does not sound thoughtful to me.
Regards,
Stephan
Pavel Machek wrote:
>Hi!
>
>
>
>>>There was a bug in one of the released Debian kernels, and do you think this
>>>hasn't happened with Redhat, SuSe, or Mandrake? Just because Debian is
>>>completely OSS and maintained mostly by unpaid volunteers, that shouldn't
>>>keep them from having a seperate tree like everyone else.
>>>
>>>
>>Just to avoid a false impression: I am in no way against debian project nor do
>>I say there is anything specifically bad about it. I am generally disliking
>>distros' ideas of having _own_ kernels. Commercial companies like SuSE or Red
>>Hat may find arguments for that which are commercially backed, debian on the
>>other hand can hardly argue commercially. From the community point of view it
>>is just nonsense. It means more work and less useable feedback.
>>Bugs is distro kernels are (always) the sole fault of their respective
>>maintainers because they actively decided _not_ to follow the mainstream and
>>made bogus patches. Why waste the appreciated work of (unpaid) debian
>>volunteers in this area? There are tons of other work left with far more
>>relevance for users than bleeding edge kernel patches...
>>
>>
>
>
>Debian is distibution; distributions are _expected_ to fix bugs (etc)
>in their packages.
>
>
not in their packages, but in their packaging, and to submit bug fixes
to the maintainers.
>If distribution had all packages unmodified, it would be useless...
>
>
not at all.
>So I'd expect all distros to have at least some changes in their
>kernel... the same way I expect distros to have some patches in
>midnight commander etc.
>
>Of course it is good to keep the .diff as small as possible.
> Pavel
>
>
I just want to say that I would happily do 10 times as much work to keep
things working for debian, but not using the vanilla kernel is a mistake
for debian, just as changing, say, xmms without involving the xmms
maintainer would be a mistake and more likely to cause bugs for users.
Just because SuSE and RedHat have lots of money doesn't mean that debian
should ape their mistakes.
--
Hans
Hi!
> > If distribution had all packages unmodified, it would be useless...
>
> Just contrary I'd state that this would be the "perfect world", because this
> would mean all projects are in perfect shape and all patches have gone to the
> respective maintainers.
Okay, in the perfect world we'd have just one distribution with all
packages unmodified. Well.. but we are not there yet.
> > So I'd expect all distros to have at least some changes in their
> > kernel... the same way I expect distros to have some patches in
> > midnight commander etc.
>
> So you say midnight commanders' maintainer is an a**hole, or what?
> If you think some project needs patches, then please talk to its
Debian having diffs vs. vanilla midnight does not mean anything
negative about its maintainer: Debian well may want different default
config, for example (F3 viewer bindings came to mind).
> > Of course it is good to keep the .diff as small as possible.
>
> diffsize small is wanted.
> diffsize zero is unwanted.
> What kind of a logic is that?
>
> Forgive me Pavel, that does not sound thoughtful to me.
If there's bug in the package, I expect Debian to fix the bug and then
forward bugfix to the maintainer.
Distribution does not want to wait for maintainer to ACK, especially
if its security-related bug.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
On Sun, 16 Nov 2003 18:05:09 +0100, Pavel Machek said:
> Okay, in the perfect world we'd have just one distribution with all
> packages unmodified. Well.. but we are not there yet.
Then why do we have a -mm kernel and a -ac kernel and a.....?
It's interesting that we've apparently decided that Andrew Morton or
Alan Cox or any of the other -initial kernel streams are allowed to have
different goals (and thus different code to achieve those goals) but
we seem to think that distributions are not allowed to do the same thing...
-exec-shield is OK if it shows up in Andrew's stuff, but not when it's
in the RedHat from whence it came? What's wrong with THAT?
On Sun, 16 Nov 2003 18:05:09 +0100
Pavel Machek <[email protected]> wrote:
> Hi!
>
> > > If distribution had all packages unmodified, it would be useless...
> >
> > Just contrary I'd state that this would be the "perfect world", because
> > this would mean all projects are in perfect shape and all patches have gone
> > to the respective maintainers.
>
> Okay, in the perfect world we'd have just one distribution with all
> packages unmodified. Well.. but we are not there yet.
Well, why not head into the right direction at least? If we didn't try that
before we would probably have never left caves ...
> > So you say midnight commanders' maintainer is an a**hole, or what?
> > If you think some project needs patches, then please talk to its
>
> Debian having diffs vs. vanilla midnight does not mean anything
> negative about its maintainer: Debian well may want different default
> config, for example (F3 viewer bindings came to mind).
Separate config diffs from original packages into new <project-config> package.
This way one can at least try to merge a new version of some rpm with a
standard distro config. diffs don't do that all to well.
> > > Of course it is good to keep the .diff as small as possible.
> >
> > diffsize small is wanted.
> > diffsize zero is unwanted.
> > What kind of a logic is that?
> >
> > Forgive me Pavel, that does not sound thoughtful to me.
>
> If there's bug in the package, I expect Debian to fix the bug and then
> forward bugfix to the maintainer.
Sorry, if there is a bug in the package I expect the maintainer to fix it and
the distributor to help him (tell him about the problem, send patch
suggestions, whatever...).
> Distribution does not want to wait for maintainer to ACK, especially
> if its security-related bug.
This is probably one reason why quite a significant amount of
distro-patches/addons are quite questionable (at least). The distro-people
cannot accept that they see only their part of the whole picture and only
_think_ that they know perfectly well what joe-average-user wants, has and
needs. In fact they mostly have no idea.
Debian could be a real win in this area if they only avoid others'
super-smartness.
Regards,
Stephan
On Sun, 16 Nov 2003 12:27:36 -0500
[email protected] wrote:
> On Sun, 16 Nov 2003 18:05:09 +0100, Pavel Machek said:
>
> > Okay, in the perfect world we'd have just one distribution with all
> > packages unmodified. Well.. but we are not there yet.
>
> Then why do we have a -mm kernel and a -ac kernel and a.....?
>
> It's interesting that we've apparently decided that Andrew Morton or
> Alan Cox or any of the other -initial kernel streams are allowed to have
> different goals (and thus different code to achieve those goals) but
> we seem to think that distributions are not allowed to do the same thing...
There is quite a simple difference in -XX kernel and a distro-patch. People
have to actively decide to use some patched kernel for whatever their reason
may be. A distro on the other hand floods the average user with patched
versions _without_ the users' active decision.
Please keep in mind that a lot of users are not capable of compiling/installing
a new kernel. Those who are have a free decision, those who are not have simply
no choice.
> -exec-shield is OK if it shows up in Andrew's stuff, but not when it's
> in the RedHat from whence it came? What's wrong with THAT?
s.a.
Regards,
Stephan
On Sun, 16 Nov 2003 18:40:12 +0100, Stephan von Krawczynski said:
> There is quite a simple difference in -XX kernel and a distro-patch. People
> have to actively decide to use some patched kernel for whatever their reason
> may be. A distro on the other hand floods the average user with patched
> versions _without_ the users' active decision.
Take it the other direction - people *also* actively choose a distro based
on some reason (to be honest, a major reason I ended up in RedHat/Fedora
rather than some other Linux distro or even a *bsd was because at the time
I needed a *nix with an X server that supported the i810 chipset, they were
the only ones shipping one pre-built).
On the flip side, I freely admit that the vast majority of things Andrew
puts in his kernel basically get flooded to me, because installing the
entire -mm patch is a lot easier than installing half of it....
On Sun, 16 Nov 2003 13:38:44 -0500
[email protected] wrote:
> On Sun, 16 Nov 2003 18:40:12 +0100, Stephan von Krawczynski said:
>
> > There is quite a simple difference in -XX kernel and a distro-patch. People
> > have to actively decide to use some patched kernel for whatever their
> > reason may be. A distro on the other hand floods the average user with
> > patched versions _without_ the users' active decision.
>
> Take it the other direction - people *also* actively choose a distro based
> on some reason (to be honest, a major reason I ended up in RedHat/Fedora
> rather than some other Linux distro or even a *bsd was because at the time
> I needed a *nix with an X server that supported the i810 chipset, they were
> the only ones shipping one pre-built).
Well, this is a good point to explain that some people choose their favourite
distro based on completely other criteria one might expect. I choose mine
because it was a european company and I found it acceptable to make a
"political decision" rather than a pure technical one. In a market that is as
imbalanced as IT towards US companies it sounded like the right thing to do for
me.
Unfortunately US companies have this special capability of reducing your choice
as a customer right down to (almost) zero - which is of course their simple
right in a free market environment.
And this is about the point where the debian project enters my picture ...
> On the flip side, I freely admit that the vast majority of things Andrew
> puts in his kernel basically get flooded to me, because installing the
> entire -mm patch is a lot easier than installing half of it....
Which is about my argument placed on a higher level of user experience ;-)
Regards,
Stephan