From: Dariush Pietrzak (eyck_at_ghost.anime.pl)
Date: Sat 27 Dec 2003 - 19:58:01 GMT
> for UP it's mostly okay, on SMP machines, there are some
> critical races, which either lock the machine or crash it ...
Oh, then since noone else is interested in fixing old ctx
then how about setting up a donation page for some corporate sponsors
to donate some SMP-capable hardware for me?
Dual ppc would be nice, thank you very much.
I guess trying to patch preemptivness in would also trigger those bugs.
> what's in a name? that which we call a rose by any other
> name would smell as sweet ...
Romeo&Juliett, nice.
I wouldn't trust blonde suicidial girls with vserver technical issues
though...
> patches (or patches patching different areas of the
> kernel) you can 'assure' good quality (no interaction)
No, by avoiding patches touching the same places I
1) reduce amount of work required to get those patches together.
2) reduce the amount of problems that arise from banging those together.
If there would be no time and equipment constraints I would create whole
kernel myself, and then write all the apps in language that I would create.
Unfortunatelly it seems like there are some teeny tiny constraints...
> you'll have to check them, to make sure ...
Hmm, oh, right, it seemes like I dodged the question and haven't really
answered it - I test first on my workstation, my setup is braindead enough
that it's realatively good indication if something works fine on it.
Then the kernel moves to my test server, this is k6-2-500 machine that has
it's own history of finding bugs in lab-tested kernels. This machine is
also populated with 'charlies', to borrow terminology from that obscure
movie people are raving about.
If it survives that I move it to production machines, then I fix small
glitches that usually surface that night and change version to uneven
number.
It's not like I'm developing anything myself, most of quality assurance
gets done by SGI - after they got burned by ptrace bug their really
stringent about what they put in their xfs-kernel CVS. Since the only
other tree I trusted - ac is on sabbatical I think this is the best
approach I could take.
For example - there is OOM missing from 2.4.23. This is huge change, if I
would just use 2.4.23 I'd be dead in the water - I run some embedded
machines, without OOM they would be disfunctional after few days/weeks of
running. But luckily I do read changelogs sometimes, and more importantly
so does SGI kernel team. So now both SGI xfs tree and my cute little
bastard are based on 2.4.24rc4, which AFAIK still includes OOM.
> > (and ensures vitality of the project, overly-ambitious
> > one-man-shows die horrible deaths..).
For example - 'folk', which was two-man-show IIRC. I don't recall it even
compiling properly once.
> > ( or you could apt-get install kernel-image-2.4.23-13d-generic )
> patches for non-debian distros are where?
http://eyck.forumakad.pl/Projects/bsd/
13e should appear there soon enough ( i'm using unison from cron to
distribute/mirror those when bandwidth is cheap, so it should be
there in the morning ).
-- Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 Namagumi namagomi namagoroshi _______________________________________________ Vserver mailing list Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver