Re: ext3 corruption

["John Stoffel" <john@stoffel.org>]

>>>>> "Molle" == Molle Bestefich <molle.bestefich@gmail.com> writes:

Molle> I guess the problem is that I don't know a single Linux
Molle> packaging system that actually works well enough to keep a
Molle> system up to date at all times, and I don't have any free time
Molle> to spend on reinstalling systems all the time.

Debian works the best in my experience.  Yum sucks rocks, it's a pain
to configured and when it does pull in stuff, it pulls in *everything*
that you don't want.  

Not that apt-get is perfect, but it works well.  My main machine at
home is an old Debian Stable install upgraded pretty much daily.
Rarely do things break.  And rarely do you want packages updated
without you thinking about it.  

If you need to maintain a bunch of systems, all at the same rev, then
you will obviously need a master system to test on and from which to
push updates to the clients.  In this case, you'd setup your own
private repository which the clients would pull from.  

Molle> I think most of the package managers break because their
Molle> dependency system sucks.  Some of them doesn't suck, but they
Molle> break because there's no integrity checks, and package
Molle> maintainers can dump any kind of bizarre corrupt dependencies
Molle> they like into them.  That's how Gentoo works, for example.
Molle> Others have even more bizarre ways of breaking, again Gentoo as
Molle> an example requires the user to run a "switch to newer GCC"
Molle> command from time to time, otherwise random packages just start
Molle> breaking.

I tried gentoo a bunch of years ago and didn't like it, and it
certainly didn't give me the speedup it claimed it would have.  I've
been happy with Debian.  Thinking about Ubuntu more...

Molle> Surely it's possible to create a kernel interface where
Molle> processes can tell the kernel about which other processes
Molle> they'd like to outlive and which ones they'd like to get killed
Molle> before.

This has nothing to do with the kernel, it's all a userspace issue.  

Molle> The kernel could then coordinate the killing of processes in a
Molle> "shutdown" function, which the various distro's 'reboot' and
Molle> 'shutdown' scripts could call.

Again, userspace completely.  You're asking for policy in the kernel,
where it doesn't belong.  

Molle> And voila, that difficult task of assessing in which order to
Molle> do things is out of the hands of distros like Red Hat, and into
Molle> the hands of those people who actually make the binaries.

*bwah hah hah!*  And you think they'll get it right?  So what happens
when two packages, call them A and B, have a circular dependency on
each other?  Who wins then?

It's not as simple an issue as you think.  

John
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/