Slashdot Mirror


What Happens To -AC (And Other) Kernel Mods?

RedLeg wrote with this poser: "So, looking at the changelog for the 2.4.9 kernel release, I see a few '- Alan Cox: driver merges' entries. Intelligent consumers of (or those of us who modify them for our own uses) RedHat Kernel src.RPMs look at the patches in the RH kernel builds. Alan's (and other persistent RH) patches don't seem to be integrated into Linus' 'mainstream' kernel trees on any kind of a predictable basis, and this frequently causes projects like freeswan to have difficulty merging their patches (not intended for kernel inclusion) with kernels that appear 'in the wild' like the kernel RPMs from RedHat. Often, kernel patches for obviously older kernel versions continue to be applied (in the RPMs) to newer kernel versions. Alan is a RedHat-er, so he obviously has an inside track to RedHat kernel builds, but he's also Linus' Right-Hand man, but his patches are not (apparently) consistently making it into the 'mainstream' kernel. What am I missing?" Who better to answer this question than Alan Cox? Alan was kind enough to write an explanation of the (still complicated) process of merging -- and it's not as simple as who works for what distro maker ;)

Note: Here's what Alan passed on in response to this question. As usual, things aren't quite as simple as they first appear. -T.

Alan Cox: Probably the first thing to explain is the Red Hat kernel. That actually isn't something I am responsible for. Arjan van de Ven is the keeper of the distribution kernel, and has the unenviable task of getting a kernel together that will actually pass all the brutal QA testing. Arjan is perfectly entitled to (and sometimes does) throw out bits of -ac changes.

You'll see Red Hat patches being merged into -ac and Linus trees when appropriate, often from Arjan or Pete Zaitcev. Many of the other patches in the RH tree are considered "fixups" - they are workarounds for problems but not generalised or clean enough to feed into the main tree without further work. Others are RH specific patches for things like packaging.

With the -ac tree I try and do rapid rolling releases, sucking in new code to test it and also its interactions with other new code. By doing releases every few days I get a high number of people testing and reporting bugs before there are too many possible causes. This is how Linus trees used to work long ago, and I still think its the better technique.

At regular intervals I take stuff from the -ac tree and feed it to Linus. Sometimes Linus doesn't want to take other changes in case they confuse other things being done, sometimes they just vanish and fairly often they get applied.

I'm actually limited in the rate I can forward patches because I need to feed Linus blocks that are debuggable. Thus I don't want to feed Linus both file system and disk driver changes at once or I won't know which to blame if there are corruption reports.

I also don't feed Linus code that has active maintainers unless the maintainer has asked me to do so. Thus the USB diverges quite a lot because Johannes Erdfelt has chosen not to feed chunks of the USB and input changes on. Similarly, the user-mode-linux port in -ac has not been fed on to Linus because Jeff Dike wishes to improve it further before submitting it.

I have been concentrating on getting the driver code and some architectures synchronized with Linus, and that is now mostly done. The next big challenge is getting all the file system work on to Linus, and Al Viro has begun that and fed Linus the first blocks of the superblock handling cleanup.

Finally we have changes that are down to fundamental disagreements, perhaps in part stemming from the fact my background is real production systems rather than OS design work. Linus decided to update the 3D support without keeping back compatibility - I kept both. Linus I suspect will never accept a patch to do that. Secondly he decided that he didn't wish to allocate new device major numbers but look for a saner solution over time. Laudible, but not in the middle of a stable release. The -ac tree has drivers allocated "non-Linus" major numbers that are recognized by LANANA and thus common across vendors. These drivers like the HPT370 and Promise IDE raid will thus always be part of the -ac tree only.

The -ac tree also tries hard to avoid any incompatibilities. Having applications that require -ac or Linus trees is simply not an acceptable situation. The only specific exception for that right now for 2.4.x is deep at the system level and is for quota tools. That one was unavoidable to get 32bit uid quota working.

164 comments

  1. Post-Mortem debugging of multithreaded processes by sllort · · Score: 5, Interesting

    One thing that's been in the -ac kernels for quite some time is the ability to post-mortem debug multithreaded processes. That is, under the production kernel, when you core dump, all the threading information is lost. You can't get the call stack of each thread. With the -ac kernels you got one core file per pid, with each LWP (lightweight process) getting its' own core file.

    Considering that Solaris has had this (what seems to be BASIC) functionality for years, why do we see the continued insistence on keeping this functionality out of the production kernel? Are we waiting for the gdb team to catch up?

    Until this is fixed, multithreaded programming under Linux will remain a black art - only developers willing to apply hordes of -ac patches to a homegrown development kernel have a change of successfully developing a multi-threaded application under Linux. Considering that many commercial software development packages (RogueWave, for instance) won't even support you if you're not using a RedHat released kernel, this puts multi-threaded development "out-of-bounds" for many.

    Merge the -ac kernel mods!

  2. I had no idea so much still needed work by Anonymous Coward · · Score: 1, Insightful

    So much for being under the impression of a "stable" kernel tree. This really discourages me, and I'm glad all my production machines are using FreeBSD where I can keep track of the CVS-synchronized sources where we don't have competing kernels.

    1. Re:I had no idea so much still needed work by SpinyNorman · · Score: 1

      The 2.2 series is still the stable kernel, not 2.4, and will probably be so for the next year. Thus spake Mr. Cox on the LKML.

      Yeah, I know it's bogus - 2.3.x should never have been dubbed 2.4 until it was stable (esp. with the rotten VM), but there you have it.

      I tried 2.4 and got bitten by the VM, so am thinking (being lazy) of switching to SuSE who have large file support merged into the 2.2 kernel.

    2. Re:I had no idea so much still needed work by Mr.Phil · · Score: 2

      well, everyone was pretty pushy about getting the 2.4 kernel out the door. Maybe linux suffered from the hype of the internet economy too?

    3. Re:I had no idea so much still needed work by NNKK · · Score: 2, Interesting

      "Competing" ?
      Without these alternate kernel trees, nothing would ever get done. the -ac trees really aren't a tree I'd recommend for a production server unless it has a fix or driver that the server desperately needs... the -ac's are to test and impliment things in advance to KEEP the "stable" tree "stable", and keep Linus happy that the patches he's putting in the mainstream tree have been tested.

      And no, I don't feel the 2.4 series deserves to be called stable, but I damn well use it anyway on my primary desktop box :)

      Linus, GIVE US 2.5 TO PLAY WITH!

    4. Re:I had no idea so much still needed work by Cro+Magnon · · Score: 1

      IIRC, Linus never said 2.4.0 was rock-solid. He said something along the lines of "The heck with it. Here it is. Enjoy!"

      --
      Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
    5. Re:I had no idea so much still needed work by krogoth · · Score: 1

      I suspect it's just the open-source release schedule - make lots of releases.

      --

      They that quote Benjamin Franklin on liberty and safety deserve neither.
    6. Re:I had no idea so much still needed work by gaydot · · Score: 1

      Amen, Brother.

      Linux is quite the maelstrom. I cannot fathom why anyone would use Linux on production boxes when other, more stable and reliable OSes are available.

      ~g.

    7. Re:I had no idea so much still needed work by Dacobi · · Score: 1

      > Amen, Brother.
      >
      > Linux is quite the maelstrom. I cannot fathom
      > why anyone would use Linux on production boxes
      > when other, more stable and reliable OSes are
      > available.

      And what are those OSes? FreeBSD, Solaris, s/390?
      And in what situations are they more stable?
      As a firewall/fileserver/desktop?
      I've been using Linux for Prodution boxes and for my personal use for about 3 years in so many ways.
      And this far the only kernel crashes I've had is with the AgpGart and NVdriver kernel modules.
      I'm not saying that *BSD and other OSes aren't more stable in some situations.
      I'm just saying that you made a pointless generalitation!

      --
      .NOT
    8. Re:I had no idea so much still needed work by NNKK · · Score: 1

      Same here, by sticking to the released kernels I have NEVER had a stability problem outside of the binary nvidia drivers except for a FEW times that were related to VERY specific hardware.
      If you experience crashes/oopses that seem to be related to the kernel, PLEASE PLEASE PLEASE report them with all possible information to the linux-kernel list.

    9. Re:I had no idea so much still needed work by gaydot · · Score: 2, Insightful



      Now I don't want to start a flame war here, but when someone says "Linux" what do they mean?

      There are so many distributions, each with little kernel tweaks (RedHat IMHO is especially bad) and different userland applications. So, I have kernel 2.4.9 with what patches, and what userland apps, what compiler, etc.? I'm totally confused. What *is* Linux?

      If I go to kernel.org and download a 30MB tarball of the kernel.... now what about the userland apps? Where do those come from? Who wrote "ps"? What version of "netstat" should I use? Which gcc compiler should I use?

      However, with an OS like FreeBSD... "FreeBSD 4.3-RELEASE" refers to one and only one kernel & userland. No questions. No confusion. If there are problems with a particular version, I can retrieve a CVS snapshot of the kernel and userland sources at any point in time since the beginning of the project. Very impressive.

      ~g.

    10. Re:I had no idea so much still needed work by Anonymous Coward · · Score: 0
      *BSD is dying

      Yet another crippling bombshell hit the beleaguered *BSD community when last month IDC confirmed that *BSD accounts for less than a fraction of 1 percent of all servers. Coming on the heels of the latest Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as further exemplified by failing dead last in the recent Sys Admin comprehensive networking test.

      You don't need to be a Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood. FreeBSD is the most endangered of them all.

      Let's keep to the facts and look at the numbers.

      OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.

      Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to another charnel house.

      All major surveys show that *BSD has steadily declined in market share. *BSD is very sick nd its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS hobbyist dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.

      *BSD is dying

    11. Re:I had no idea so much still needed work by Anonymous Coward · · Score: 0

      I get 'panics' with the word (?) 'aieee...' in it, is that significant? 2.2.something. I didn't really bother, I use win 95 if I want serious useability, I only use linux for serving porn on my intranet.

    12. Re:I had no idea so much still needed work by Cramer · · Score: 2

      If anyone remembers, back when linux rolled to the spankin' version "1.0", Linus said, "Calm down children. It's just a number." The quote may not be 100% correct as this was many years ago, but the part about the version being "just a number" is as true today as it was then.

      Linus and company may know how to write code, but it's very obvious they were never taught to manage all of their code. Talk about a black art. Linus' hatred of CVS doesn't make things any easier.

    13. Re:I had no idea so much still needed work by NNKK · · Score: 1

      ahh yes, the usability that doesn't allow you such things as right clicking on the taskbar to change settings...

      if you're going to troll by calling a Windows system more usable than linux, at least use something PLAUSABLE, like win98, in your examples...

    14. Re:I had no idea so much still needed work by Anonymous Coward · · Score: 0

      Until now, my friend. Since you've commented on it, I shall developer Extreme FreeBSDee, which will hopefully bring all distribution problems to the FreeBSD world.

    15. Re:I had no idea so much still needed work by Cramer · · Score: 2

      Well, there's stable and then there's stable... 2.4 was, what, over a year past due for release? How many 1.3 kernel revisions were there before 2.0 was declared?

      A lot of things could be done differently. They, of course, won't because Linus hates CVS. Personally, I'd prefer something along the lines of ClearCase, but I'm paying for the licenses :-) It's time consuming work -- over 50% of work load at Make Systems was configuration management related stuff and there were only a few dozen people working on code.

      Anyone who knows anything about code management knows what a "code freeze" is. They also know to begin working within new branches (long) before freezing previous branches. 2.5 should have been open for development when 2.3 was "frozen". And certainly parts of the current 2.4 tree don't belong there -- bug fixes and isolated back ports from the development branch are all that should be going into the 2.4 line. Additionally, it's hard to construct a schedule when you have no clear direction -- a list of features to be in X and which features are push further down the line.

      Of course, I don't what the kernel versions to start looking like Cisco IOS tags :-)

    16. Re:I had no idea so much still needed work by Hard_Code · · Score: 2

      CVS has well earned it's hate. I'm all for version control, but CVS is an ugly hackish piece of crap. I sure wish Subversion would get completed (or at least releasable). As it is, CVS has too much momentum behind it because it "just works" (or "sorta" works). One of the curses of the Unix mentality (have separate tools which only do one specific thing), is tools that just *barely* do the job enough to scratch the particular developer's itch. Unfortunately version control is not that sexy.

      --

      It's 10 PM. Do you know if you're un-American?
    17. Re:I had no idea so much still needed work by Cramer · · Score: 1

      Have you ever used ClearCase from Rational Software (Atria, whatever)? It's very sexy. That is, for any org that cares about source code management.

    18. Re:I had no idea so much still needed work by Thing+1 · · Score: 1
      Linus' hatred of CVS doesn't make things any easier.

      If Linus hates CVS, why not set up a Perforce server for him? I was recently looking at their web site, and saw that Open Source developers can obtain licenses for FREE!

      It's more powerful than CVS, and has a great user community to help solve problems.

      I just downloaded it, installed it, and started submitting files in about an hour -- and half that was the download (modems suck, especially after having had ADSL, 1-way cable, and 2-way cable).

      No relation to Perforce, just very pleased with their interface and their attitude.

      --
      I feel fantastic, and I'm still alive.
    19. Re:I had no idea so much still needed work by Thing+1 · · Score: 1
      They, of course, won't because Linus hates CVS.

      You should mention to Linus that Perforce is giving free licenses to Open Source developers; the GNU GPL v2 or higher is sufficient.

      Perforce is very flexible, a great system. Plus there's a great user community.

      One advantage Perforce has over CVS is it groups a number of files into a "submit". A submit is atomic: if anything goes wrong it rolls everything else back. Change numbers describe a submission, then, not a single file. This is very useful -- you can see which files a person touched at once, either to see how he was thinking while working, or if maintenance is required, it's easy to find all the changes that went into his contribution to the source tree -- there all described by a single change number.

      --
      I feel fantastic, and I'm still alive.
    20. Re:I had no idea so much still needed work by Tony-A · · Score: 1

      Nah, Windows 95, the patched OEM version. (The stable Windows 95 that you couldn't buy from Microsoft ;-) It's been downhill ever since.

  3. Yeah but by Frequanaut · · Score: 1



    When is the MAX_MAP_COUNT fix going to make it into the mainstream kernel?

    1. Re:Yeah but by Alan+Cox · · Score: 5, Interesting

      The goal there is to make it unneccessary. 2.4.8-ac7/ac8 have slightly smarter VM merging behaviour done by Ben LaHaise for example.

    2. Re:Yeah but by Anomymous+Coward · · Score: 0

      ok, and what about the 3com driver/APIC updates that were supposedly fixed in the -ac tree (the ones that kept SMP boxes with APIC handling from dying under high network load with 3c905 network cards?), are these ever going to make it into the linus kernel?

      We had to go buy new cards, because upgrading from 2.2 to 2.4 made backups impossible, as high network/processor load caused problems at least one night a week, forcing us to power cycle the backup machine.

  4. Wait a minute by bconway · · Score: 2

    With the -ac tree I try and do rapid rolling releases, sucking in new code to test it and also its interactions with other new code. By doing releases every few days I get a high number of people testing and reporting bugs before there are too many possible causes. This is how Linus trees used to work long ago, and I still think its the better technique.

    Perhaps he meant the unstable series Linus releases. I sure as hell would NOT like to see a new "stable" kernel release every few days. The current faux-schedule of a new release every couple of weeks seems a bit too quick for decent testing to me, to tell you the truth.

    --
    Interested in open source engine management for your Subaru?
    1. Re:Wait a minute by Alan+Cox · · Score: 4, Informative

      You make an assumption that the right way to test code is in big lumps. That is somethiny any engineer will tell you is bogus.

      You test continually, you test each changeset, and then every so often you run a several day shakedown test.

      You are right that you can't QA a kernel to vendor production grade in two weeks. Some of the RH test runs take several days per run for example.

    2. Re:Wait a minute by bluGill · · Score: 2

      Sure, but sometimes you have to test all at once.

      I've worked on projects before where the hardware was only partially stable, and the rom code was changed daily and normally couldn't boot. Those doing higher level work on the system were forced to write code for the specs, and debug latter. It isn't the best, but it works. (Yes there is simulation, but simulation tends to comment out all the hardware interaction, which changes things drasticly)

    3. Re:Wait a minute by spudnic · · Score: 2

      So you do that in the deveopment tree, not the stable one.

      It's crazy to have stable releases coming out as often as we do. There is no way that you could change enough in the kernel to justify a new stable release 2 weeks (or less) later unless it was a to fix a major oversight (read: bug) in the previous stable release. You just don't have time to test things out.

      --
      load "linux",8,1
    4. Re:Wait a minute by Anonymous Coward · · Score: 0

      the "official reason" is that linus wsa going on vacation and wanted it out the door.

      but i secretly believe there was a huge security problem with all the previous kernels dating back to the 2.0 kernel. only linus knows about it and so he didn't want to tell anyone about it because there is security in obsecurity and all that.

      you should update NOW!

    5. Re:Wait a minute by Anonymous Coward · · Score: 0

      Read the changelogs. That is the rate of innovation in the Linux world. It doesn't mean everyone should be rushing out and trying each tree unless they are doing it for fun.

    6. Re:Wait a minute by binford2k · · Score: 1

      I hope you aren't serious. If you are, then you are a complete paranoid dumbass.

    7. Re:Wait a minute by NNKK · · Score: 1

      Hmmm... I guess you don't read the changelog very closely do you? More fixes and additions go into each new kernel version than you would find in many updates for commercial closed-source software.
      With most changes, for example, a driver fix, you don't need to test out the whole kernel, just things that deal specificaly with that driver.

      And yes, there are bugs in every "stable" release, there are bugs in every "stable" release of all software.

      Go monitor the changelog and the linux-kernel list for a couple weeks, and you'll understand why stable kernels are released within 2-4 weeks of eachother.And no, monitoring the KernelTraffic summaries DOES NOT COUNT as monitoring linux-kernel, far more goes on than KT summarizes.

  5. Re:Post-Mortem debugging of multithreaded processe by scorpioX · · Score: 3, Informative

    Max OS X has this feature as well. If you set CRASHDEBUG=-YES- in /etc/hostconfig, you will get a dump of all thread stacks and the CPU(s) registers when a process bombs out. Very handy. I believe that HP-UX also has this feature. Surprising that Linux doesn't.

  6. Alan misunderstood the question by DonkPunch · · Score: 1

    No, no, no. The question was, "What happens to AC posts about VALinux and Microsoft?"

    --

    Save the whales. Feed the hungry. Free the mallocs.
    1. Re:Alan misunderstood the question by Anonymous Coward · · Score: 0

      What is "all dissenting posts are deleted by Taco & co", Alex?

  7. Re:Post-Mortem debugging of multithreaded processe by Anonymous Coward · · Score: 0

    Linus dislikes multithreading, so why would he support it?

  8. from the cyfrifiadurol dept... by JJGreenaway · · Score: 4, Informative

    In case anyones wondering 'cyfrifiadurol' isn't a typo. It's Welsh roughly meaning 'to do with computers'.

    And before anyone says it, yes, computers have reached Wales now...

    1. Re:from the cyfrifiadurol dept... by Syberghost · · Score: 1

      And before anyone says it, yes, computers have reached Wales now...

      Better not run Harpoon on them, or Greenpeace will be pissed.

    2. Re:from the cyfrifiadurol dept... by scrytch · · Score: 3, Funny

      > And before anyone says it, yes, computers have reached Wales now

      yeah but the cost of classified ads in the paper is prohibitive when they're looking for programmers in llyncyrfdlywrfldycrlycywwcrynrfrwnr...

      i'd like to buy a vowel.

      (oh crap i think i just called someone's mother a really nasty name)

      --
      I've finally had it: until slashdot gets article moderation, I am not coming back.
    3. Re:from the cyfrifiadurol dept... by Anonymous Coward · · Score: 0

      Welsh is a typo.

    4. Re:from the cyfrifiadurol dept... by LatJoor · · Score: 1

      I don't know any Welsh, but from what I do know of other languages and the history of the Latin alphabet I would guess that the Y *is* a vowel, and thus that word seems perfectly pronounceable.

    5. Re:from the cyfrifiadurol dept... by randombit · · Score: 1
      I don't know any Welsh, but from what I do know of other languages and the history of the Latin alphabet I would guess that the Y *is* a vowel, and thus that word seems perfectly pronounceable.

      Yeah. I don't know Welsh either, but my grandparents do, and it's not half as unpronouncable as it looks. I guess we're getting offtopic here, but whatever.

      This is the first time in a while there was an ask slashdot that was both interesting (compare to say the Dorm Storm one a while back), and informative (Alan Cox r00lz, though he may not appreciate me saying it in such a manner).

    6. Re:from the cyfrifiadurol dept... by shippo · · Score: 1

      W is also a vowel. The ISO 8852 charset designed for Wales contains both W and Y with accents.

    7. Re:from the cyfrifiadurol dept... by iainl · · Score: 1

      Heading rapidly further from the topic, I'll confirm that. Its a bloody good job too, otherwise me having a middle name of 'Rhys' would be rather complicated. Mind you, even the word 'by' would be a bit fiddly without the wonder that is using y as a vowel. Welsh uses w as a vowel too, e.g. in 'cwrs', which is perfectly simple to pronounce really.

      --
      "I Know You Are But What Am I?"
    8. Re:from the cyfrifiadurol dept... by CMBurns · · Score: 1

      > I would guess that the Y *is* a vowel

      Argh... you "GUESS that the Y *is* a vowel"? Guess again.

      Man, are you american or what? An second question: Has America some sort of IQ-restriction for every citizen. Like, say, a maximum of 5? Even dry bread is smarter than you guys.

      C. M. Burns

    9. Re:from the cyfrifiadurol dept... by Anonymous Coward · · Score: 1, Informative

      Argh... you "GUESS that the Y *is* a vowel"? Guess again.

      I'm not sure what you mean here, but it's obvious that you're a real moron. Some letters have different pronunciations in different languages, and 'y' is one of those. In English it is either vowel or consonant depending on the context, which is actually an orthographic mistake in my opinion. This usage comes from Middle French, though. (French has dropped the 'y' in most places, compare old "roy" with modern "roi.") In Latin, as far as I understand it was always a vowel which was used to represent the 'u' sound like in French (like the 'ue'/u+umlaut sound in German). (That's a front high rounded vowel, for the phonetically informed.) This came from Greek and was used only in writing Greek words, since no native Latin word uses the sound. The same goes for old English. In a popular transcription system for Russian, 'y' represents the letter whick looks roughly like Ib in Russian (high middle unrounded vowel?). In many newer writing systems, such as Wolof (to take one that I speak), 'y' is always a consonant, a palatal glide like in "yes."

      As a more logical alternative, many languages, such as Dutch, German and Polish, have chosen to use 'j' for the sound equivalent to the English consonant 'y'. This is really more sensible, because 'j' is derived from 'i', which in Latin was used for both a consonant and a vowel, like 'y' in modern English. The practice orginated among scribes wishing to make Latin texts more clear, so they added a little curl at the bottom of the i's that were consonants. People in Central Europe picked this up when developing writing systems for their own vernacular langauges.

      So, although I can't say I know any Welsh, I do know a thing or two about languages and alphabets. Why don't you think before you open your fool mouth next time?

  9. Don't be a playa hata by Anonymous Coward · · Score: 0

    Alan is a RedHat-er

    Hey, I'm a Red Hater too! Debian R00L$ J3W!

    1. Re:Don't be a playa hata by Glanz · · Score: 0, Troll

      RH gloppy splodge vs MS glimey splidge: may the worst money-muncher loose! In the very MEAN time, I will debunk my territory with Debian too as the free BSDers squabble and bitchfight on the gaybar floor, and OS X tries to appeal to Xers, and Microslop slops the server security of the world, and as red hat charges $3,000 smackers to begin to approach the illusion of security in a MS dominated vinyl-fetished "granny needs virtual sex too" world.

      --
      Rien n'est plus beau que le creux du 0.
    2. Re:Don't be a playa hata by Anonymous Coward · · Score: 0

      you know you should really see someone about that

    3. Re:Don't be a playa hata by Glanz · · Score: 1

      Thanks COWARD, or do you prefer Anonymous.

      --
      Rien n'est plus beau que le creux du 0.
  10. Ask Slashdot by zpengo · · Score: 1, Offtopic

    WTF is going on with the front page?

    --


    Got Rhinos?
  11. I think by wiredog · · Score: 2

    That their database is still Having Issues. We need a story on what's going on there.

  12. How about getting XFS in -ac? by Brian+Knotts · · Score: 1

    Please?

    1. Re:How about getting XFS in -ac? by Dante · · Score: 1

      He has commented about this before on linux-kernel. Search, read, be enlightened.

      For now it's... no, with good reason. IMHO XFS is the best thing sense sliced bread. In very informal testing it works best out of all the jornaling FSs that I have played with.

      --
      "think of it as evolution in action"
    2. Re:How about getting XFS in -ac? by Brian+Knotts · · Score: 1
      Well, I just searched linux-kernel, to no avail. I can find nothing where the problem with merging XFS is explained.

      I have heard that it has to do with the fact that XFS changes some other things in the kernel outside of the actual filesystem code, but I don't know if that's actually the problem.

      I just hope we don't end up with one or more forks of the kernel because of this.

    3. Re:How about getting XFS in -ac? by Dante · · Score: 1

      Hmm, well. It was a topic last week. maybe it has not hit the lists yet. basicly it (XFS) changes more then just a few things, and more then a new FS should. I know it makes changes to the VM, and scheduling.

      There was more info then that, but I hate para-phrasing other people.

      Don't you wish there was a built in spell check in slashcode? But then again it keeps me from being too verbose. :>

      --
      "think of it as evolution in action"
    4. Re:How about getting XFS in -ac? by Keith+Owens · · Score: 1
      The XFS patch splits into 7 major components:
      1. XFS only code. Approx 4Mb of new files for XFS only.
      2. Easy patches to existing files. These add new functions and definitions which are only used by XFS, plus changes to existing Makefiles. It also changes some VM functions to cater for delayed block allocation which only XFS supports. These changes have no affect on VM except for XFS pages.
      3. Tricky patches to existing files. The extra facilities of XFS require extra parameters on some existing VM functions.
      4. LVM updates. The lvm code in 2.4.x has bugs which XFS trips, so we have to include lvm updates in the XFS patch. With the recent announcment of LVM 1.0 this patch should disappear.
      5. Kernel Debugger. SGI maintain kdb and it is included in the XFS tree for ease of use by the XFS developers.
      6. Miscellaneous patches. These include adding XFS to defconfig, setting EXTRAVERSION, workarounds for kernel bugs such as min/max not handling pointers. It also includes kbuild 2.5 changes, XFS is ready for kbuild 2.5.
      7. Extended attributes and ACLs. XFS optionally supports extended attributes and Attribute Control Lists. This is not a core requirement for XFS and there is at least one other group working on ACLs, so this code is separated from the core XFS.

      Only the first three patch sets are required to get the core XFS functionality. The other four are nice to have but not mandatory. SGI have repeatedly sent the first three sets to Linus, without any response.

      If any kernel distributor (including -ac) wants the individual XFS patches, just ask. SGI do not make them generally available because they are snapshots which are only created as required. The normal method of getting XFS is from CVS or as a release, both of which include all the patch sets.

    5. Re:How about getting XFS in -ac? by Brian+Knotts · · Score: 2
      Thanks for the information! I'd sure like to hear from the other side; why do they seem to be ignoring the XFS team?

      I really am very impressed with XFS; it seems like solid, proven code. I think XFS has the best chance at being the heavy-duty file system for Linux.

    6. Re:How about getting XFS in -ac? by Martin+Maciaszek · · Score: 1

      You will probably have to merge XFS into -ac yourself. Some time ago the same question has beeen asked on the linux-xfs mailing list and one of the developers stated that it would be to hard to keep track of the -ac patches. Alan can produce his patches "at an alarming rate" :)

  13. I can appreciate the problem by jd · · Score: 4, Interesting
    The FOLK project (gratuitous plug!) runs into all sorts of problems, all the time, from inconsistancies, patch for A being out of sync with patch for B, etc, etc, etc.


    That's one of the reasons I started that project, in the first place. Because it's mind-numbingly tedious to massage patches from different groups together. If you can get the whole thing in one gigantic gloopy splodge, life would be much easier.


    Unfortunately, I've discovered a number of things along the way:

    • Debugging said gloopy splodge is a Royal Pain!
    • Finding others who will help debug said gloopy splodge is not easy.
    • Finding others who will even -report- bugs in said gloopy splodge isn't easy, ether.


    That's not to say that FOLK is a disaster. Quite the opposite! I'm learning a huge amount about the Linux kernel, for a start, and the sheer complexity of juggling hundreds of patches is really giving my C coding skills a workout and a half!


    My hat is off to Alan Cox who not only manages his patch set with far more grace than I ever could, but actually keeps it so that it runs!


    I know the Royal Web Admin uses Linux (cos that was on an interview, some time ago), so if he's reading & has any influence, I honestly think Sir Cox would not be an undeserved title for his amazing computing skills and his contribution to both computing and Britain.

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
    1. Re:I can appreciate the problem by Anonymous Coward · · Score: 0

      I can appreciate the problem of you having too damn much whitespace in your freakin' posts.

      You think your little mumbling insights are entitled to my ENTIRE browser window or something?

    2. Re:I can appreciate the problem by 4of12 · · Score: 2

      Lameness filter encountered. Post aborted!

      Thanks. I'll keep my thoughts to myself from now on. Between this Innovation® and the new unavoidable link to the front page of the site that started to afflict "older stuff" I'm about ready to fugged about /. entirely.

      --
      "Provided by the management for your protection."
    3. Re:I can appreciate the problem by jbreker · · Score: 1

      get a bigger monitor. can you say 21" display baby

    4. Re:I can appreciate the problem by wolf- · · Score: 1

      I hear you.
      Comments not being accepted for lameness, or because I type too quickly, or a missing field or some ass error.

      Who let this new slashcode into a production environment? Was it ever really tested?

      /me thinks it wasn;t

      --
      ----- LoboSoft specializes in Digital Language Lab
  14. Promise IDE RAID by blackwizard · · Score: 2

    I didn't know the -ac trees had Promise IDE RAID support. I looked all over for a good solution for using that thing, after I carefully soldered on my resistor, only to find out that there was no good Linux support for the darned thing. Has anyone had any success using this thing in Linux (not using the closed-source drivers?) This is something I'd really like to see in a stable kernel.. does anybody know how to tell what -ac releases are stable, if any? **pounding head on cubicle wall** I suppose I can use software RAID if that's what it comes down to.

    1. Re:Promise IDE RAID by Tony+Hoyle · · Score: 3, Informative

      The Promise RAID *is* software RAID. All the kernel can give you is access to the extra IDE ports (which is does).

    2. Re:Promise IDE RAID by Sunthalazar · · Score: 2, Informative

      I don't know specifically about the Promise IDE RAID, but I do know about the HPT370 RAID. They are actually included together.
      All I can really say is that it's not quite perfect. I'm using an on-board HPT370 [it's part of my Abit VP-6], and under Win2K I don't think I've had any crashes [well other than some reproducable ones that are things that I've done]
      But I've used the -ac patches in 2.4.6-2.4.8 and so far there is still a couple of times when my machine will just lock up. It seems to be related to disk access, but it also only happens when I'm running X. Without X, I haven't had any problems [although I can't run Mozilla or XMMS, etc without X]
      In general, though, it recognizes and runs fine. I haven't had any general data inconsistency [I run ReiserFS on the RAID partitions]
      Again, this is for the HPT370, not the Promise IDE RAID, but since they are in the same kernel patch, I figured their results would be similar.

    3. Re:Promise IDE RAID by zulux · · Score: 1

      I second that - the Promise Raid controller has a bit of a BIOS hack that allows it to work with MS-DOS. Of couse, that BIOS hack is being run by your main processor. After the initial boot, the Promise Raid just becomes a slightly weird Promise IDE controller, and needs drivers in your operating system in order to do it's Raid bit. Check out 3Ware if you need hardware IDE Raid. Because it's hardware - you don't have the driver problems.

      --

      Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.

    4. Re:Promise IDE RAID by ahodgson · · Score: 1

      If you want good hardware raid, get a 3ware board.

    5. Re:Promise IDE RAID by EvlG · · Score: 2

      That is because the highpoint chips are crap.

      I had a HPT366 in my Abit BE6 and have had nothing but problems with it. I won't buy another board that uses a highpoint - they are junk.

    6. Re:Promise IDE RAID by randombit · · Score: 1

      I second that - the Promise Raid controller has a bit of a BIOS hack that allows it to work with MS-DOS. Of couse, that BIOS hack is being run by your main processor. After the initial boot, the Promise Raid just becomes a slightly weird Promise IDE controller, and needs drivers in your operating system in order to do it's Raid bit.

      Yeah, same thing with the Abit KT7A-RAID board. Actually IIRC that's a promise board too, just built into the motherboard.

      Those extra ATA/100s are really nice for doing software RAID, though.

  15. We know what happens to AC by Anonymous Coward · · Score: 0, Funny

    He gets modded down.

  16. Look... by Anonymous Coward · · Score: 0
    You've gotta tone it down a little. Keep at this, and everybody (including clueless slashbots) are going to know that it's phony.

    Don't do this on every god-damned story, and don't bother if you're at like 70th post, ok fuckwad?

    Idiot.

  17. Don't Feed the Linus by grammar+fascist · · Score: 2, Funny

    At regular intervals I take stuff from the -ac tree and feed it to Linus.

    ...because I need to feed Linus blocks that are debuggable. Thus I don't want to feed Linus both file system and disk driver changes at once...

    I also don't feed Linus code that has active maintainers unless the maintainer has asked me to do so.

    So Linus eats code. Everything is so clear now...

    --
    I got my Linux laptop at System76.
    1. Re:Don't Feed the Linus by Red+Moose · · Score: 2, Funny

      Didn't you know? Linus is like that dolphin from Johnny Mnemonic, only he's a penguin instead. And he's got loads of hi-tec stuff strapped on his head and can track submarines and doing linux is only a part-time thing, really.

      --

      Acting stupid isn't much fun when there's someone around who knows better

    2. Re:Don't Feed the Linus by ethereal · · Score: 2, Funny

      So does that mean Alan Cox is really Ice-T? [shudder]

      --

      Your right to not believe: Americans United for Separation of Church and

  18. Ahem. by nomis80 · · Score: 1

    "At regular intervals I take stuff from the -ac tree and feed it to Linus."

    Take that out of context and think about it.

  19. Why aren't you guys using CVS? by sds · · Score: 1

    I remember claims that Linus what "the CVS with brains", but when there are two trees (AC and Linus) it would seem that CVS is a must.
    What is holding AC and Linus (aside from having to learn how to use CVS)?

    1. Re:Why aren't you guys using CVS? by Splork · · Score: 1

      Even with CVS there would still be two branches and the pain of seperating patches out for merging from one branch to another. Let the patch managers decide if they want to use it. CVS doesn't solve this problem by itself.

      Its worth noting that several subsystems of linux are maintained under their own CVS repositories, with patches being seperated out into functional units and sent to Alan or Linus to sync the project up.

    2. Re:Why aren't you guys using CVS? by j-pimp · · Score: 1

      They don't want CVS becasue they want people to be able to submit a bug report for a particular kernel. Yeah its a crapy system in some regards, but it allows Linus to have better control on what is and is not worthy of being official kernel. Alot of the really cool stuff in the kernel now suchy as QT and GTK in the frame buffer and kernel Cobra (ok that was just silly) isn't in FreeBSD because FreeBSD development is more "committee" based. Then again FreeBSD is alot easier to admin then most linux distros.
      cvsup -g ${SUPFILE}&& cd /src/src && make world && shutdown -r now
      Linux kernel development is organized in a way to encourage these maverick kernels.

      --
      --- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
    3. Re:Why aren't you guys using CVS? by elbles · · Score: 1

      I agree with you on the topic of Linux using CVS. BUT, BSD, in its earlier days, was created mainly by Bill Joy. Bill Joy's equivilent (sp?) in the Linux world would be Linus Torvalds. In the early days of BSD, Bill Joy controlled, for the most part, what went in BSD. There wasn't even CVS back that far . . . onc Joy left, then BSD got more "open" to the ideas and patches of others. The same thing may happen with Linux, if and when Linus decides to move on.

    4. Re:Why aren't you guys using CVS? by NNKK · · Score: 1

      Well, even if Linus does move on before he dies, I imagine Alan Cox would probably be the most likely candidate to takeover development of the mainstream kernel when Linus decides he's burnt-out. While he probably wouldn't be as conservative as Linus is with it, I don't think things would change too drasticaly.

    5. Re:Why aren't you guys using CVS? by Anonymous Coward · · Score: 0

      CVS is most convinient for a long-term
      divergent work, such as a port. For
      that reason DaveM, Cort, Ralf and some
      other port maintainers keep CVS trees.

      The -ac tree needs self-contained patchsets,
      which is more convinient with patch.

      Red Hat kernel is also kept in CVS, *BUT*
      it is a very unusually structured - it keeps
      ONLY PATCHES.

      I must note that it takes a certain amount
      of habit to figure how to use patch/diff
      efficiently. I fumbled with them for years.
      My simple rules are:
      1. KEEP BASE TREES (actually, Alan mentioned
      to me that he uses patch -R often. Here I
      discuss _my_ habits, not his :)
      2. Always diff -urN -X dontdiff, otherwise
      you _will_ forget
      3. Stick for -u and new-after-old argument order
      (well, this is obvious...)
      4. Structure patch archive, use descriptive
      patch headers and patch filenames.

      BTW, RMK has a beutiful and useful patch manager
      http://www.arm.linux.org.uk/developer/patches/

      -- zaitcev

  20. Re:Post-Mortem debugging of multithreaded processe by n0ano · · Score: 5, Informative
    The thread core dump patch was originally put into Alan's tree around the 2.4.3 time frame. It was quite correctly labeled experimental at the time (it took a few iterations to get it right.) The intent is to merge it into Linus' tree at some time, it just hasn't gotten there yet.


    In the mean time, if you're desperate, I can give you a patch that provides this capability to any Linus tree.

    --
    Don Dugger
    "Censeo Toto nos in Kansa esse decisse." - D. Gale
  21. Re:Post-Mortem debugging of multithreaded processe by cnkeller · · Score: 2

    Someone mod this parent up. Seems like a worthwhile patch.

    --

    there are no stupid questions, but there are a lot of inquisitive idiots

  22. -AC by Heem · · Score: 1

    Without -AC it could get pretty -HOT

    --
    Don't Tread on Me
  23. OMG!!!! by siliconvortex · · Score: 1

    Slashdot researched a submission! Beware, the anti-christ may rise soon!

  24. All my confidence in Linux is lost forever by fobbman · · Score: 4, Funny

    What Happens To -AC (And Other) Kernel Mods?

    I'm sorry, but if the kernel has a bunch of modifications done by people who find it necessary to be referred to as the initials for Anonymous Coward then how can we trust the security of the kernel?

    They get modded down on /. but then get merged into the kernel source? Let's make a stand and stick to it!

    Oh, and I copied these comments to a text file so I can repost it in the event that /. pukes up it's guts again.

    1. Re:All my confidence in Linux is lost forever by Anonymous Coward · · Score: 0

      "Never trust anybody with the initials H.C.^H^H^H^H A.C" -- agbard Celine

    2. Re:All my confidence in Linux is lost forever by jbreker · · Score: 1

      ahh im pretty sure that ac stands for Alan Cox. maybe not but its a guess.

    3. Re:All my confidence in Linux is lost forever by Anonymous Coward · · Score: 0

      sarcasm, my friend, sarcasm.

    4. Re:All my confidence in Linux is lost forever by Cyno · · Score: 1

      I'm just glad the moderation system on /. doesn't decide which patches get added to the linux kernel. Just imagine how buggy linux would become if we all had a say in what gets added and what doesn't. But perhaps we'd get linux to beat windows in 3d frame rates and downtime.

    5. Re:All my confidence in Linux is lost forever by Anonymous Coward · · Score: 0

      sarcasm? Yea what about it?

  25. Re: The Truth About CmdrTaco, VA, and Microsoft by Anonymous Coward · · Score: 0

    You are damn right about it and so was the original poster. However, just like he mentioned in the parent (shame I cannot link from here), /. seems to be turning into the same thing they critiziced a few days ago: astroturfing. Let me tell you one thing: the credibility of this site is at serious risk unless Taco explains the original acusations.

  26. Re: The Truth About CmdrTaco, VA, and Microsoft by Anonymous+Pancake · · Score: 0

    where is the parent post for this?

    looks like someone has been doing some cens0ring

  27. (OT)Slashdot does not censor. by yerricde · · Score: 1

    There's a big double yellow line with orange traffic cones between improving signal-to-noise and censorship. Slashdot is slalom-skating it.

    Ever since CmdrTaco and friends created the moderation system, Slashdot has intentionally deleted exactly one comment, and it was a flagrant copyright infringement. If you browse Slashdot at -1, you'll see everything.

    --
    Will I retire or break 10K?
    1. Re:(OT)Slashdot does not censor. by Anonymous Coward · · Score: 0
      They don't, eh? Then how do you explain this?


      Along with the other evidence, it seems fairly convincing.

    2. Re:(OT)Slashdot does not censor. by Rick+the+Red · · Score: 1, Offtopic
      Then where's the Parent to this comment (#2204931)? What's its number, so we can all read it? If you check the "Parent" link in that comment, you'll see it points to comment zero (0). Either the parent has been deleted, or the "Parent" link has been altered. Now, who can make changes like that around here...? Can you? I sure can't!

      --
      If all this should have a reason, we would be the last to know.
    3. Re:(OT)Slashdot does not censor. by Anonymous Coward · · Score: 0

      Indeed. I have noticed many, many comments with abortive parents. Unless it's possible to specifically create a comment that is attached to a cid which doesn't exist, comments ARE regularly being deleted by the /. crew.

      What a bunch of hosers.

      Then again, in this litigious day and age of America, pretty much any dissenting opinion you could possibly have will land you a date in court with some big hefty corporate or government lawyers breathing down your neck.

      Then again, WTF ever happened to civil disobedience? Screw libel laws! This isn't even a true journalistic resource. The authors are ALWAYS giving their opinions. (Though an argument could be made that they often try to pass off their slanted views as fact -- something newspapers do quite consistently.) With the exception of this particular article, none of the "journalists" here ever even bother to do any research other than applying the knowledge they might already have at the top of their heads.

    4. Re:(OT)Slashdot does not censor. by NullAndVoid · · Score: 1

      Elvis did it.

      --


      -- Sigs are for losers
    5. Re:(OT)Slashdot does not censor. by Teancom · · Score: 1

      I've noticed many, many, comments with abortive parents, that couldn't possibly have been offensive and/or libelous. I would guess that they are having problems with their database or code, both of which are brand new (if you haven't seen the couple stories on it lately). Much more likely than all of a sudden a /. editor going on a rampage with the delete key.

  28. AC patches: who needs 'em? by n8willis · · Score: 1
    As far as I'm concerned, no anonymous coward has the right to expect his patch to make it into the mainstream kernel. Let's have some accountability, people!


    Nate


    (I'm sorry; I had to do it....)

    --
    -- Watch the REAL Jon Katz.
  29. Re:Little brown ring, little brown ring by Anonymous Coward · · Score: 0

    Yay! ASCII goatse-man lives!

  30. Re:I think ... it ate my journal entry! by Sun+Tzu · · Score: 2

    Yes, indeed it is having problems.... My journal entry was made about 24 hours ago. It was gone this morning so we've had maybe over a day of problems now.

    Give us an update, CT!

    Oh, and ignore the 'game client' link below -- if it is still there. Yesterday it pointed to my journal entry.

  31. Re: The Truth About CmdrTaco, VA, and Microsoft by Anonymous Coward · · Score: 0

    or have the trolls uncovered an new 'sploit of the article numbering scheme? (like how they can get first post before the article hits the front page...)

    Actually, I had noticed one of my surly trolls "disapperaring" after first showing up. Whether intentional or not, it's damn suspicious.

    Truly, these are interesting times for /.

  32. freeswan by Anonymous Coward · · Score: 0
    This wasn't the main point of the post, so ignore if you don't care about freeswan.

    Freeswan is an incredible piece of junk. After 1.5+ years of talking about it, klips2 is still going nowhere, and freeswan is still a bloated, hacked-together, syntactical and administrative nightmare. After a year, there's still no support for AES; obviously the developers think talking about klips2 for another 5 years is more important than providing an alternative to the incredibly slow 3des algorithm, which is the only one currently supported.

    Not to mention the developers are a bunch of paranoids who refuse to accept contributions from anyone in the US or any US citizens for fear of retroactive encryption export regulations being re-imposed. The only activities I've seen from the developers, really, are occassional bug fixes, attendance of ipsec cookoffs, and general bickering on their mailing lists whenever someone complains that freeswan is going nowhere.

  33. The BSDs solved this long ago by howardjp · · Score: 1

    You know, the BSD's solved this long ago by allowing more open modification of the official kernels.

  34. A Canonical Response by llywrch · · Score: 2

    > "At regular intervals I take stuff from the -ac tree and feed it to Linus."

    > Take that out of context and think about it.

    Just because Alan Cox is east of the US doesn't mean he is a snake.

    And why are all of you handing me my coat?

    Geoff

    --
    I think I see a trend here. Maybe for them it really would be easier to muzzle the entire internet than to produce p
  35. ac tree... by jmccay · · Score: 1

    Where would on see this ac tree growing? err... I mean where can I find the code tree/patches?

    --
    At the next eco-hypocrisy-meeting, count the private jets used to get to the meeting. Should be interesting to see that
    1. Re:ac tree... by abdulwahid · · Score: 1

      You can find Alan's kernel patches Here

      --
      perl -e 'print $i=pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10);'
  36. Athlon CPU support should (EXPERIMENTAL) by WyldOne · · Score: 1

    I never had as much trouble with the 2.4.5-9 kernels & support for the Athlon CPU. Talk about buggy. I finally had to switch to PIII as CPU before I had a stable kernel again.

    --

    make Linux, not Microsoft. sin(beast) = -0.809016994374947424102293417182819
    1. Re:Athlon CPU support should (EXPERIMENTAL) by Anonymous Coward · · Score: 1, Informative

      Athlon CPU support is rock solid. Certain combinations of VIA chipset motherboards and AMD Athlon processors seem to leave a lot to be desired

      Avoiding the streaming memory fetches will help on most of those boards (ie optimise for PII or K6)

    2. Re:Athlon CPU support should (EXPERIMENTAL) by OblongPlatypus · · Score: 2

      I thought that was a bug in a VIA chipset? I'm pretty sure the Athlon optimization stuff is pretty rock solid and definitely not experimental. I'd hate for them to start slapping the (EXPERIMENTAL) label on anything which might cause problems or conflicts on some specific platforms. (Although that's what MS did with their latest OS, didn't they...)

      --
      -- If no truths are spoken then no lies can hide --
    3. Re:Athlon CPU support should (EXPERIMENTAL) by NNKK · · Score: 1

      There have been some issues with Athlon optimizations, however you don't have to use Athlon optimizations when compiling your kernel.
      I've had NO trouble with Athlon optimizations in 2.4.7 and 2.4.8 and now 2.4.8-ac9.

      Most of the Athlon problems reported in the past have been problems with VIA's chipsets, which I label as "devil-spawn".

  37. Re:Alan Cox patch script by mighty+jebus · · Score: 0

    this hasn't been moderated down yet because no one with mod points speaks sed. how appropriate.

    --
    Leading the partnership for a Slashdot-Free Slashdot, Son of Dog
  38. this is the begining of the end for linux by Anonymous Coward · · Score: 0

    Amen!

  39. Re:Al Cocks & Linus Toreballs by Anonymous Coward · · Score: 0

    well said, my son, well said ..

  40. Methinks YHBT by Anonymous Coward · · Score: 0

    'nuff said.

  41. Re: The Truth About CmdrTaco, VA, and Microsoft by Anonymous+Pancake · · Score: 0

    people dont understand how important the trolls are.. if it weren't for trolls I would have left slashdot long ago.. they are the only people who make me want to come back here daily... I'm sure at least 10% of the people who visit slashdot, and see the banners and click the banners and help slashdot pay the bills only come to troll or to view trolls. The day the trolls die is the day slashdot loses alot of it's community

  42. Am I the only one??? by Anonymous Coward · · Score: 0

    What I read from the origional post:

    'Why doesn't the "wild kernel" (read: the official one from Linus) not include the same patches as the RedHat kernel? It causes trouble when projects depend on these patches being included in the kernel and they aren't there!'

    My answer:

    Ummm...it is not Linus's fault that developers depend on unofficial kernel code that RH, in their infinite wisdom, has added to their kernel. RH is NOT the official kernel, Linus's is! Please let my know what projects these are so I can stear clear of them...

    Noah (jik-)

  43. My bad.... by Anonymous Coward · · Score: 0

    Oh, I misinterpreted....the developers seem to be targeting the official kernel and not the RH one.

    The problem is still not with Linus, it is with RedHat. If they must release the kernel modified they need to make it plain that this is the case so users don't get confused and toss a fit when a kernel patch doesn't apply...

  44. -stable vs -current ? by MavEtJu · · Score: 1

    Have a look on how FreeBSD does handle this:
    Instead of having only one tree, there are two: the -stable and the -current. -current is the tree with the newest features and active development going on, the tree which might, or might not, compile, the tree which might, or might not, break your system. The -stable tree is the tree in which everything works, which has no real new active development (all development is done in -current), only merges from the -current track are coming back into it.

    For more information, see http://www.freebsd.org/doc/en_US.ISO8859-1/books/h andbook/current-stable.html

    --
    bash$ :(){ :|:&};:
    1. Re:-stable vs -current ? by RustyTaco · · Score: 1
      Instead of having only one tree, there are two: the -stable and the -current.
      You mean even and odd?(2.2 & 2.3, 2.4 & 2.5)
      It's allready there. There isn't any real active development allowed on 2.4, period. It's all fixes and clean ups. Once 2.5 hits then we'll see nifty stuff like a new console subsystem, making everything happy with hotplugging, maybe a few new FS's being merged and other subsystem reorganisations.

      - RustyTaco
    2. Re:-stable vs -current ? by Anonymous Coward · · Score: 0
      *BSD is dying

      Yet nother crippling bombshell hit the beleaguered *BSD community when last month IDC confirmed that *BSD accounts for less than a fraction of 1 percent of all servers. Coming on the heels of the latest Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as further exemplified by failing dead last in the recent Sys Admin comprehensive networking test.

      You don't need to be a Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood. FreeBSD is the most endangered of them all.

      Let's keep to the facts and look at the numbers.

      OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.

      Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to another charnel house.

      All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS hobbyist dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For ll practical purposes, *BSD is dead.

      *BS is dying

    3. Re:-stable vs -current ? by NNKK · · Score: 1

      Uh, this is already done, both in the kernel and in many linux distributions (slackware, debian, even redhat has Rawhide)
      those -preXX kernel versions are the "unstable" releases (so to speak) of the vanilla kernel tree. the odd-numbered kernels are development kernels that don't even come close to being stable enough to be called unstable.

      the -ac kernels are not simply -stable vs -current, a severely unstable patch that might break things isn't going to intentionaly make it into -ac kernels... you could think of -ac kernels as a testbed for future intigration into the mainstream kernel, but that doesn't make it unstable on the level you're talking about with FreeBSD's -current, that level of instability is reserved for the odd-numbered kernel series (i.e. 2.3 and the forthcoming 2.5).

      One does wonder though what clueless businesses that already know odd=unstable for the kernel will think when 3.0 arrives :)

    4. Re:-stable vs -current ? by Builder · · Score: 1

      The comments about it already being done are not strictly true. ReiserFS was introduced in 2.4.1 after feature freeze. There is no way that you can say ReiserFS was a bugfix. That is big time new development.

  45. AIC 7880 driver is flawless! I'm now up from 2.4.3 by NRAdude · · Score: 0

    I am realy stoked at the 2.4.9 linux kernel release. On my system, originally LFS with kernel 2.4.3, the kernel always hung when I used my SCSI Kenwood TrueX 52X Ultra CDROM drive on my integrated AIC 7880 SCSI Host(built-in AHA2440 UltraWide). It'll detect my two Quantum Atlas harddrives and at the time it detects the CDROM it just says it found CDROM sr0 and it gets a bus timeout of some kind. Linux kernel 2.0.35 or rather the 2.0 series of kernels amazingly have no problem with detecting my system configuration. The 2.2 kernel and the early 2.4 kernel has problems with it. Might I add this is only a problem with the Adaptect aic 788x driver/module. Other SCSI controllers worked find with this drive and now I can put everything back on the integrated scsi and get back my PCI clot. Sad to say, I relented to installing MS Windows95 on a separate, but temporary, 200MB partition and MS Windows didn't have a problem from the start. I never tried using the 2.4.3 kernel and a 2.0.36 AIC 7880 driver and I doubt it would've worked when and if I tried. I don't experiment with this system of mine. It takes 3 minutes for it to boot and I like linux because I don't have to reboot it when I someone walks into my office and sneezes or yells "Dohnut"! Linux 2.4.9 made my day. Thanks Linus and all you elite hax0rz.

    --
    without prejudice
  46. there is a simple solution to that mess: by Anonymous Coward · · Score: 0
    upgrade to FreeBSD
    :-)


    seriously, I think linus and al. should inspire themselves from the FreeBSD model, and get a working team and clear release/build model instead of the "linus is king" approach.

    Some collaborative work would do a lot of good, I think.

    1. Re:there is a simple solution to that mess: by Anonymous Coward · · Score: 0
      *BSDis dying


      Yet another crippling bombshell hit the beleaguered *BSD
      community when last month IDC confirmed that *BSD accounts for
      less than a fraction of 1 percent of all servers. Coming on the heels of
      the latest Netcraft survey which plainly states that *BSD hs lost more
      market share, this news serves to reinforce what we've known all along.
      *BSD is collapsing in complete disarray, as further exemplified by

      failing dead last in the recent Sys Admin
      comprehensive networking test.

      You don't need to be a
      Kreskin to predict
      *BSD's future. The hand writing is on the wall: *BSD faces a bleak
      future.
      In fact there won't be any future at all for *BSD because
      *BSD is dying. Things are looking very bad for *BSD. As many
      of us are already aware, *BSD continues to lose market share. Red ink
      flows like a river of blood. FreeBSD is the most endangered of them all.

      Let's keep to the facts and look at the numbers.

      OpenBSD leader
      Theo states that there are 7000 users of OpenBSD. How many users of NetBSD
      are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet
      is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400
      NetBSD users. BSD/OS posts on Usenet are about half of the volume of
      NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent
      article put FreeBSD at about 80 percent of the *BSD market. Therefore
      there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with
      the number of FreeBSD Usenet posts.

      Due to the troubles of Walnut
      Creek, abysmal sales and so on, FreeBSD went out of business and was
      taken over by BSDI who sell another troubled OS. Now BSDI is also dead,
      its corpse turned over to another charnel house.

      All major surveys
      show that *BSD has steadily declined in market share. *BSD is very sick
      nd its long term survival prospects are very dim. If *BSD is to
      survive at all it will be among OS hobbyist dabblers. *BSD continues
      to decay. Nothing short of a miracle could save it at this point in
      time. For ll practical purposes, *BSD is dead.


      *BS is dying

  47. you can do WHAT?!?! by bungatron · · Score: 1

    you can compile the kernel with -ac? "Allow anonymous coward posts"? Reckless!

  48. Re:Post-Mortem debugging of multithreaded processe by Mark+Kettenis · · Score: 2, Informative

    As a member of the GDB team (maintainer of the Linux/i386 port and co-maintainer of the threads support in GDB) I'm not aware of any coordination between the kernel folks an GDB at all. On top of that I'm not inclined to add support for this to GDB until it ends up in Linus' kernel. Anyway, the one-core-file-per-pid approach seems wrong to me. It's a waste of disk space since you're duplicating the VM for every pid. And isn't well suited to how GDB deals with multi-threaded core files on other platforms. A better approach would be to add an additional note with the register contents for each LWP to the same core file.

  49. Re:Post-Mortem debugging of multithreaded processe by Anonymous Coward · · Score: 0

    Someone mod the parent down. Seems like a worthless comment.

  50. Alan's Kernel is becoming more "official" by trevorcor · · Score: 2, Interesting

    This is very interesting:
    http://www.uwsg.indiana.edu/hypermail/linux/kernel /0108.2/0416.html

    It seems Alan Cox is considering his -ac kernel tree to be a legitimate alternative to the official "Linus" tree, rather than a playground for testing patches. He's actually perpetuating a difference between -ac and the official tree, in a way that breaks source compatibility between the two (albeit in a very small way.) The fact that RedHat's kernels are all based on -ac now bears this out.

    Alan has forked the Linux kernel.

    ::meyhem::

    I think he has Linus' blessing in this though. Reading between the lines, I think Alan has been taking on more and more work in the past year or so that had previously been Linus'. Linux is ten years old now; I suppose Linus is burning out.

    And Alan works for RedHat too, which is one of the two distributions that I *know* will be around in ten more years -- they have a solid business plan. Alan is voracious, just tireless, and RedHat would hire the entire core kernel development team if they had to. Linux will not die for lack of a maintainer if Linus gets hit by a bus tomorrow.

    --
    "That's all I have to say about that" --Forrest Gump
  51. Re:Random Crap by Anonymous Coward · · Score: 0

    Interesting. The result seems to be you are modded down. This is a huge discovery, and will rock the slashdot science community.

    I am writting a paper on these observations. You will soon see it on the front page of slashdot, under the science section.

    Thank you for your contributions. We couldn't have done it without you LondenBerg.

  52. Unit testing? (was Re:Wait a minute) by ulmer · · Score: 1

    Okay, I'll stick my foot in some place for which I don't have time to volunteer... :)

    What if the direction was set to "require" developers to submit unit tests for their modules along with them? In not too long it would be possible to *shudder* regression test the entire kernel.

    How is the QA testing of the Red Hat Kernel done now? WOuld it be easier or harder to integrate a test suite into the kernel source itself?

  53. Re:Alan's Kernel is becoming more "Stable" by Anonymous Coward · · Score: 0

    Since 2.4 is the stable branch, Alan will be starting to take over maintainance of the Tree, freeing up Linus to start work on 2.5.

  54. Re:Something I'd like to see... by NRAdude · · Score: 0

    this feature has been around for many, many years and with similar setup and ease of use. Goto freshmeat.net and look for "amd" which is the auto-mount daemon. It is more stable than supermount if you are into the command-line(console) thing. If you mount or umount a drive when being used by supermount; it'll freak out and act weird. "amd" works by you easily accessing /auto/cdrom or /auto/zip instead of mounting /mnt/cdrom or /mnt/zip and reading from within the /mnt directory which is what supermount does.

    --
    without prejudice
  55. Re: The Truth About CmdrTaco, VA, and Microsoft by Anonymous Coward · · Score: 0
    Exactly. Whatever you want to call it, this is not a serious discussion site. Oh sure, there are a few monumentally clueless folks who are still trying to use it that way, but hey -- for those of us who know better, it's a massively multiplayer online game, and a fun one. There are all sorts of ways to keep score -- first post, karma, biters on trolls, etc.

    Slashdot even behaves like a game company. Bad support, ignoring customer feedback, and releasing beta-quality patches that radically alter gameplay!

    Why pay for some shit Anarchy Online when you can post to /. for free?

  56. Re:Something I'd like to see... by autechre · · Score: 1

    Eek! No! Use of amd is not exactly encouraged any more; you should really be using autofs. You need to compile support for this in the kernel, and your distribution should have the userspace tools.

    --
    WMBC freeform/independent online radio.
  57. Why aren't you guys using Aegis? by Anonymous Coward · · Score: 0

    CVS is just a (simple/complex) tool and will not work easing the development process. Aegis does have a development process model, and wont let you integrate a change until it compiles, is tested and reviewed. It might be hard though to harness the testing in such a way that aegis can work with it. I may be rather hard to get a test result if you test for some kernel panic and the result is positive...

  58. HPT366 needs hdparm for stability by korpiq · · Score: 2

    This is what I use with an external HPT366 to have it run stable:

    /sbin/hdparm -c 3 -m 16 -u 0

    cheers

    --

    I think, therefore thoughts exist. Ego is just an impression.
  59. Sir Alan Cox by Anonymous Coward · · Score: 0

    Don't they give out titles to ordinary ppl that deserve it if enough ppl ask 4 it, maybe we should start a campaign, next time their gonna give em out :-)

  60. Re:Post-Mortem debugging of multithreaded processe by Anonymous Coward · · Score: 0

    Someone mod the parent down, seems I am needlessly carrying on a stupid thing.

    Doh

  61. Re:Post-Mortem debugging of multithreaded processe by Anonymous Coward · · Score: 0

    It would work only on UP, not SMP systems, it's not possible to "stop" all related threads on all CPU at fault time. The all-thread-to-one-core approach is racey.

    Anyway, there are very good reasons why Linus, Alan Cox, David S. Miller, Ingo Molnar, Al Viro and all other big names are against threads: in short they just want Linux to stay a stable, secure and well-performer platform.

  62. Linux distributions by oli_freyr · · Score: 1

    I read somewhere that you should regard the various distributions as distinct, yet fairly compatible OSes.

    Therefore, Red Hat 7.1 is a complete OS with a well defined (perhaps only internally documented) list of utilities/applications at well known individual version stages. Then you can compare RedHat 7.1 with FreeBSD 4.3-RELEASE to find out how they compare.

    To answer your question: Linux is the kernel used by compatible OSes, known as "Linux distributions".

  63. Quota version by Anonymous Coward · · Score: 0

    I'm using reiserfs with quota support but their patch is against linus kernels, therefore I need to also patch the quota utilities version 1.70.

    The newest quota utils 3.x seems to already have reiserfs support, but don't work with linus kernel.

    Will this mess be solved at near future? Why linus don't want the new quota code in his kernel?

  64. Re:Random Crap by londenberg · · Score: 1

    In particular I was interested in seeing what messages would show up for me in the new Slashdot messenging system. I got notes for both time I was mod'ed -1 Offtopic, and notifying me of your reply.

    Thank you for you assistance in my (not so) scientific experiment.

  65. Re: The Truth About CmdrTaco, VA, and Microsoft by Tony-A · · Score: 1

    Some things are too important to be taken seriously. /. seems to me more like a soap opera, and just as addictive.