Re: Still Considering Debian - But Stuck!
This is not a problem. The 2.4 kernel is included in the current Debian release, it is just
not the default. All of my Debian boxes are set up for 2.4 kernel (no need to compile unless
you want it more efficient). Also, ext3 is standard, just not the default.
Probably better ways to do it, but I simply do a standard install, then go into dselect,
choose the 2.4.28 kernel for my processor, then install (you have to make one minor mod to
/etc/lilo.conf manually). Then, I run e2fsck -j (I believe that is correct) on the volumes I
want to have journaling. NOTE: I believe /boot can not be ext3.
You can even put reiser on if you like.
Rod
> Hi Everyone,
>
> A while back I asked for some feedback and got a very rich set of info
> from folks about Debian used in a stable ISP environment as compared to
> other OS's and distributions. All the info was very helpful and helped
> us further solidify our desire (though not yet decision) to make Debian
> our platform as we move forward.
>
> We've run into a couple rather HUGE issues, though, that I'd like to get
> further feedback on. Not that I couldn't figure it all out for myself,
> but nothing beats someone else's experience when it comes to saving me
> the time and heartache ;-) Just about everyone warned me that the
> stable Debian distribution would be old and well tested/maintained, but
> I'm not sure I was prepared for just HOW old...
>
> Our company uses Java --- a LOT of Java. We therefore use a lot of
> threads, and a lot of threads. And a whole mess of threads, too. Under
> Red Hat 7.3, we found that when the system had a total of say, 10,000
> PID's given out (nearly all of them to threads) the system would become
> very unstable. When we moved to Red Hat 9 for the affected systems,
> which includes the new 0(1) scheduler, and either a different kind of
> thread support in either the kernel or GlibC, this problem went away.
> I'm honestly not sure who is responsible for the way threads are
> handled, and I suspect it's not exclusively the kernel, but under RH9
> each JVM (or any app with threads) gets a single PID as normal and all
> very strange behavior that we saw under RH7.3 disappears.
>
> I see that Debian 3.0r2 includes a nicely aged (like fine cheese) Linux
> 2.2 kernel. While I'm certain the aging process only makes its flavour
> stronger and more delectable, I'm afraid it's going to choke at the
> thought of 10,000 threads. Say nothing of 20,000. Now I imagine it's
> not so difficult to simply compile a recent 2.4 (2.5?) kernel and go
> from there. Is this fair? Or would you suppose that the current stable
> Debian is too old in other areas to properly handle kernel 2.4?
>
> Even if I replace the kernel, I'm concerned that there's more involved
> with the more efficient handling of threads from RH 7.3 to RH 9 than
> just a kernel change -- I have to think there was a significant rework
> of some libraries that made threads more efficient under RH9 as well.
> Would anyone be able to identify exactly what that re-working was, and
> conjecture if they think it can be done under 3.0r2? For that matter,
> would I at that point be running so much new technology that I may as
> well be running an unstable distribution of Debian?
>
> Finally, while I'm messing around with the kernel, I'd have to include
> support for ext3fs. In our environment, journaling is not an option,
> it's a base requirement. Of course replacing the kernel would pretty
> much give me kernel-level support for it. From that point, how
> complicated is it to get the rest of the tools to play nicely with
> ext3fs? I'd imagine that a large set of tools would need to be
> replaced, including e2fsck, mount, umount, etc.
>
> Thanks once again for all the info so far!
>
> -Fred Whipple
>
>
> --
> To UNSUBSCRIBE, email to debian-isp-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
--
Media Ethics is an oxymoron, much like Jumbo Shrimp and Microsoft Works. Not to mention NT
Security
Reply to: