> On Sun, 7 Feb 1999, Alexander Viro wrote:
> > Without dependency on details of VFS internals.
> >
> I'm not so sure if this is possible effectively. May be yes, may be no.
If you are not sure - RTFSource or shut up.
> > Gee... How nice. Maybe your know a spell that would magically fix NFS in
> > this round of changes? That's what I'm fighting with right now. And
> > [U]MSDOS, for that matter (less terrible). Most of them will be fixed
> > already... Sheesh... Sure they wiil. Do you realize that things that are
> > PITA in 3rd-party modules are PITA in the official ones? No? Yes, they
> > will be fixed. Just that 3rd-party stuff is pain in the asses of its
> > maintainers while the stuff in official kernel is pain in my ass right
> > now. Code is code and breakage is breakage, no matter where the breakage
> > happens.
> >
> No. There is difference. Not from mantainer side of course but from
> end-user side. Looks like you could not understood that not all peoples
And I should give a flying damn for any (end-)luser. Why? Please,
try to realize that problems with binary incompatibility in modules are
much more serious than any end-lusers' delusions. End-luser has no f*cking
business to upgrade/rebuild anything. It's not simple on any OS. Leave it
to admin.
> are kernel developers out there :-)) From mantainer of NFS and AFS this
> breakage is the same PITA, but from end-user point of view there are big
> difference: if it's included in tarball then chances are high that with
> new releases changes will be done before new release will be put for
> download (if this will break ext2fs, for example, then Linus will not
> accept patch in first place ;-) and from END USER point of view this
> breakage will not be noticeable at all. If something is not included in
> tarball then user should wait for mantainer to catch up.
Oh, horror! They told on SlashDot that there is a k3w1 n3w r3133z and
3133t d00d burned his sorry ass. Luser dies, we die, grass turns
purple and also dies, sun turns into the black hole and sucks the whole
Galaxy in. Everyone die. Oh, embarrasment!
Seriously, WTF are you talking about? All this stuff about separate
tarballs was around splitting a single tree into parts and letting people
to download what they need. WTF does it have to module interface changes
and/or somebody downloading parts of different releases, compiling them to
Frankenstein monster and frying its ass?
> > Yeah??? In case you've missed it: d_move() call goes out of foo_rename()s
> > and moves to vfs_rename(). And it's not idempotent[1]. If that wouldn't
> > happen there would be no need even to recompile modules. Problem with
> > those advocates - they can vgrep but they can't read. Sheesh...
> >
> I'm not used neither vgrep nor some other grep. Looks like you really do
vgrep (n.): visual grep. I.e. looking through the text in search
for some familiar sentence.
> not want understood that there are exist some peoples except of kernel
> developers. For THEM it's big difference if something is included in
> tarball or not...
You used to be a Komsomol activist, didn't you? You know, there is
some difference between l-k and meeting.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/