Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Linux Software

Call For Linux 2.5 Testers 39

An anonymous reader writes "Linus has put out a call for testers with the release of 2.5.40. IDE appears to be in working condition, and the only really obvious thing that could be a problem anymore is the lack of any working volume manager... (LVM is b0rk, atm) So unless that's a problem, start your kernel compiles."
This discussion has been archived. No new comments can be posted.

Call For Linux 2.5 Testers

Comments Filter:
  • by burns210 ( 572621 ) <maburns@gmail.com> on Tuesday October 01, 2002 @11:57PM (#4371603) Homepage Journal
    if we actually get people testing this, then we won't have to wait serveral versions down the 2.6.x (or is it 3.0.x) road before it is considered stable.

    • It's comments like, "there's no working volume manager at the moment," that scare the hell out of me.

      I run Linux for my back-end fileservers at work, and am in the middle of adding more. Right now I just use one partition per disk, and so I end up with a bunch of partitions.

      I would dearly love to use some kind of striping RAID, or at least a concatenation. But when the LVM-type code keeps getting rewritten between every release, it's just too risky. I look with longing at my Sun boxes, where DiskSuite has been doing Jus' Fine[tm] for the past several years, and continues to be supported.

  • Members of the kernel development community don't seem to agree that the development kernel will function on IDE drives without destroying them...

    Maybe instead of bloating the featureset, they should be working on getting the I/O working?
    • by Kynde ( 324134 ) <kynde@[ ].fi ['iki' in gap]> on Wednesday October 02, 2002 @02:47AM (#4372093)
      Members of the kernel development community don't seem to agree that the development kernel will function on IDE drives without destroying them...

      Maybe instead of bloating the featureset, they should be working on getting the I/O working?


      I/O? Are you seriously complaining that the IO thruput is lacking? I'm guessing you're talking about the interactive feel.

      So and so, but I bet you don't even run 2.5.X. Granted the 2.4 imho is still interactively crap. It's been ever since the vm "improvement" starting with 2.4.10-preX and how last fall those fscking db-benchmarkers showed up on lkml. I bet they got their 1% improvements for their db and on the same they bollocksed my developement desktop usability to a level it felt like win95. Atleast I learned a lot more about the vm and scheduling internals and loads of neat tricks how to improve latency (e.g. more memory and no, Hz up, neg-nicing X, nicing back ground stuff, A.Morton's low latency and lock breaking patches.)

      BUT I must say that the 2.5 is a step forward from 2.4 also in this manner. I've been running 2.5s all along and these late 2.5.30s, especially 2.5.39, have been goodish. Not the kind of interactivity as there should be, still.

      Although I'm still seriously pissed off how all the main developers seemed to disregard all the cries about interactivity last fall and winter on lkml. There SHOULD be a proc or even a compile time possibility to tweak it into serverish/db or desktop usage. On a desktop developement you couldn't care less if your compile or what ever the fsck you're doing on the back ground takes 5% longer, but if what ever you're actually interacting with lags like hell, it annoys the living crap out of you. I mean, if I press the button while I'm compiling, obviously that button press is more important ffs.
    • Maybe instead of bloating the featureset, they should be working on getting the I/O working?

      Well, they have. It's been an interesting period. First, Andre Hedrick stopped being the 2.5 IDE maintainer. (There were apparently "interface concerns" with him an Linus, but I haven't seen this so sorry if I'm wrong ^^; ) Martin Dalecki sent in over 100 "clean-up" IDE patches, most of which got merged at the time. Unfortunately, a lot of people didn't like the way they were going and eventually he kind of got chased off. By this time it's July or so. Since then the situation has been a general throwing up of hands followed by forward-porting the improvements made in the -ac tree by Andre Hedrick. There are also other issues, like the fact that ATA (protocol) tends to be ugly and have odd (mis)implementations in hardware. Consequently, people who *really* grok IDE are at a premium.

      Hey, there have been other issues to take care of in 2.5 as well, so I don't find this particularly surprising.

      In any case, there's no real point in complaining about "feature bloat". That's what make menuconfig is for ;)

  • by Zeio ( 325157 ) on Wednesday October 02, 2002 @12:35AM (#4371727)
    I just got RedHat 8.0 (psyche) up and working last night (full install over 4GB, no JFS or XFS options during install, only EXT3/2), with their gcc-3.2, all the stuff done just right (that is to say, the RedHat way, I don' not use RedHat or Linux much anymore, I use FreeBSD but like to pay attention to Linux). I've been having problems with getting the 2.5.xx series to compile cleanly of late, lots of broken patches seem to make it into this thing, which is to be expected at this stage in the game. One thing I wish was a requisite before the kernel version is revved is that everything compiles and if it doesn't I gets flagged as such in the configurators so one doesn't spend copious amounts of time figuring stuff like that out empirically. 2.5.40 also crashed out of "make menuconfig" if I went into the ALSA section. I wish that the release process for Linux would get a bit more refined, using a source management tool was step one, now I think its time to build a base system around Linux to ensure me of more things when I get it. You could say, get a standalone kernel, or more desirable, a mini system with a c library and compiler and some tools - so that the kernel guys say, we know it works here, with this compiler, and this library, that's what we use. This is coherency I enjoy in other places. This isn't to say Linux isn't meritorious, quite to the contrary, but I would personally like to see things differently - I'm sure I'm re-hashing something that has been said a billion times already. I just though it ironic that 2.5.40 doesn't compile on RedHat 8.0 release -strange considering a good number of the RedHat people are kernel hackers.

    Linux distributions vary wildly in their various eclectic incarnations as to how things are supposed to get done. My favorite system I have seen thus far is Gentoo. I like to see source usage encouraged, base system clearly defined, reference design and methods of extension al la ports (or emerge).

    An open question, if I have suggestions or problems, is there a place for people who don't have time to live and die by Linux to "drop it in the suggestion box?" I had some problems here and there in the past and have found that people "don't want to hear it." I don't mind being incorrect, but I don't take correction without explanation. I have yet to year why there is a good reason for things that don't compile being checked into 2.4.STABLE - which I also follow.

    So as far as beta testing goes for Linux kernel. Do they want beta testers? The attitude on the mailing lists ranges from super helpful (some code maintainers are very good about dealing with breakage) to this "if you cant write a better implementation, FO, I don't want to hear its broke, don't like it don't use it". In any case, how is it exactly us trying to use this kernel going to help the better it if the method of information ingress is unclear? Is there a procedure? Like Mozilla when it faults, you get to send errors in, stuff like that. Is there a memory dump in the kernel yet or is that still a patch (it's a tradition that kernels dump to swap then copy on boot do you can see what the computer was doing if it panics). One thing about Linux - if you compile it, load the crap out of it to test it, if it doesn't panic in the 1st day it seems to never panic - which is good.

    Just an FYI for people getting into kernel stuff with RedHat-ish systems:

    Getting Linux via bitkeeper.
    First, get BitKeeper:


    http://www.bitmover.com/cgi-bin/download.cgi [bitmover.com]

    Follow the instructions and it will tell you how to download and install BitKeeper.

    Then, clone the main Linux tree using BitKeeper:
    $ cd /usr/src/linux-2.5.40
    (or wherever you would like your stuff)
    $ bk clone bk://linux.bkbits.net/linux-2.5
    $ ln -s linux-2.5.40 linux
    $ (optional if needed, ln -s linux-2.5.40 linux-2.4 ; ln -s linux-2.5.40 linux-2.5) - sometimes dists and weird driver SRPMS look for linux/include in all sorts of places
    $ cd linux
    $ bk -r co

    Also don't forget.

    - /usr/src/linux , /usr/src/scsi ; /usr/src/asm ; /usr/src/asm-generic should all be re-linked to the right places in /usr/src/linux/include [if this is no longer necessary let me know]
    - make install doesn't work with grub, so you have to do your thing manually now
    - recommended compiler is gcc-2.9.5.3 [for 2.4 and 2.5 now], I always have extra compilers ready to go just in case. Make sure all the tools are the proper version, and that you have a recent ksymoops (if you need to do any messing around looking for problems ), modutils - etc.

    If the build fails, find the offending code and remove from selection, or try to hack it if you need it.
    • Getting Bitkeeper (Score:1, Informative)

      by Anonymous Coward
      Damn YAFCTWMEA (Yet another fucking company that wants my email address).

      To get bitkeeper, go to this url [bitmover.com]. If that doesn't work, the username is 'bitkeeper' and the password is 'get bitkeeper'.

      Egad, the kernel source is being maintained with a proprietary, binary-only tool!??! Does this strike anyone else as severely ironic? (Not to mention maybe a bad idea?)

      • I thought so too, but if the Bitkeeper company goes bankrupt the source goes free, and it's the first code management software that Linux has ever had and apparently Linus likes it. It apparently helps development.

        It'd be nice to hear what Linus thinks of it after a few months of use. I remember after a few weeks he hadn't yet settled into the software.

    • From this article [linuxworld.com]:

      The use of Bitkeeper for the Linux sources has a grave effect on the free software community, because anyone who wants to closely track patches to Linux can only do it by installing that non-free program. There must be dozens or even hundreds of kernel hackers who have done this. Most of them are gradually convincing themselves that it is ok to use non-free software, in order to avoid a sense of cognitive dissonance about the presence of Bitkeeper on their machines. What can be done about this?

      One solution is to set up another repository for the Linux sources, using CVS or another free version control system, and arranging to load new versions into it automatically. This could use Bitkeeper to access the latest revisions, then install the new revisions into CVS. That update process could run automatically and frequently.
      • I do agree BK is technically wrong and think that RMS is right in this case. I would like for them (those who decide where Linux sources live, Tosatti, Linux, Cox, et. al.) to use Subversion, or maybe even CVS and a program like cvsup like on FreeBSD - seems to work more than adequately for a project which a much larger in scope than just a kernel. RMS can seem loony at times, but in this case I agree with his argument. Non free software is not a desirable end because I contest the argument that, in this specific case, non free software is necessarily better. Not with competition like Subversion. Not when you weight the ramifications of a heavy thick restrictive license which is "worse" than GPL. (I can not personally decide on BSD vs. GPL licensing, but I lean towards BSD because it's a good compromise to allow corporations to leverage meritorious free/open work while being able to tweak and tune to a platform without giving away too many specifics) but random proprietary license of the day and reams of EULA trash don't belong in the center piece of the GNU/Linux arena, IMHO.
    • You gave the instructions to fetch the latest version of the 2.5 tree. To test this release the right command is:

      bk clone -rv2.5.40 bk://linux.bkbits.net/linux-2.5 linux-2.5.40

      That said you should only do the clone if you don't already have a bitkeeper tree somewhere. Doing local clone and a pull is MUCH faster.

      -Wayne
  • I've been up on 2.5.40 for over 8 hours now, without any problems. Of course I'm not loading it badly, just Mozilla and doing some additional kernel compiles.

    But, it definitely appears stable enough to do some testing without worrying about trashing your system.

  • Does anybody know why the need to change the IDE code arose?

    Did the IDE specs change, or something about filesystem management in general?
    • Re:IDE problems? (Score:2, Informative)

      by sir99 ( 517110 )
      There was no real need to change the IDE code, but some people felt it was a mess and needed to be cleaned up. Unfortunately, it broke badly in the process, so the 2.4 IDE was ported to 2.5, putting things back pretty much as they were. Kernel Traffic [zork.net] is a good source of information about all this stuff. Of course, this is a vast oversimplification, and some of the activity was due to your standard mailing list flame war.

  • I actually grabbed 2.5.39 a few days ago, all
    ready to upgrade my home system out and give
    it a good play.

    After fixing 4 compile-stopper errors (yes, they've been reported on the kernel lists) I gave up.

    Sorry, but if the thing hasn't even been tested to see if it /compiles/, that's not even good enough for a non-production, but still a pain to restore from backups home machine. I wasn't
    even using obscure device drivers or compile
    options.

    (This is on PPC btw, one of the major platforms)

    I'm happy to run development kernels and report
    bugs/issues. But when the risk of having to reinstall from backups gets too high, sorry, that's just too much work.

    I accept that some development kernels will be substantially broken while major changes are happening, but those ones aren't the ones that people should be encouraged to test.

    - MugginsM
  • Does the author imply that LVM is broken? If so, why?

    If LVM can really do what it claims to do (allow to treat several partitions/disks as one logical volume) than it's really cool. Never had a chance to experiment with it though.
    • by Anonymous Coward
      LVM will not compile in 2.5. We're waiting for the LVM folk to either push a patch that gives us LVM2 or fix the existing LVM.

      The interfaces were changed under it, and nobody seemed to want to fix it.
  • if make menuconfig bombs out when you try to configure it with make menuconfig, do this with the following file: patch -p1 alsapatch.txt

    the first line is --- lin... and the last line is the 2nd --

    --- linux-2.5.40/sound/Config.in Tue Oct 1 04:06:30 2002
    +++ linux-2.5/sound/Config.in Wed Oct 2 07:27:04 2002
    @@ -31,10 +31,7 @@
    if [ "$CONFIG_SND" != "n" -a "$CONFIG_ARM" = "y" ]; then
    source sound/arm/Config.in
    fi
    -if [ "$CONFIG_SND" != "n" -a "$CONFIG_SPARC32" = "y" ]; then
    - source sound/sparc/Config.in
    -fi
    -if [ "$CONFIG_SND" != "n" -a "$CONFIG_SPARC64" = "y" ]; then
    +if [ "$CONFIG_SND" != "n" -a "$CONFIG_SPARC32" = "y" ] || [ "$CONFIG_SND" != "n" -a "$CONFIG_SPARC64" = "y" ];then
    source sound/sparc/Config.in
    fi

    --

    --
  • A nice way to dip your toes in the 2.5 kernel pool without risking your main system is with User-mode Linux [usermodelinux.org].
  • Only three problems to mention: (1) "Advanced Linux Sound Architecture" menuconfig option crashes 'make menuconfig'. (2) Netfilter's 'Owner Match' does not compile as a module. (3) Possible problem after reboot with 'modprobe char-major-10-135'. This was all done on a Redhat 7.2 system w/ Create Live! card, 3Com 3c905b card, P3 850 Mhz w/ 256 MB RAM, and a 40 GB ATA5 HDD. The system seemed to speed up a good deal after rebooting into 2.5.40. These errors have been reported to linux-kernel@vger, so hopefully they'll be looked at soon. It seems 'make menuconfig' has changed in architecture slightly...it's a little bit more logical, and the help sections have been worked out well. I think all in all the Linux kernel should be bumped up to 3.0 just because of all the memory management upgrades and preemptiveness. I know 2.0 came about with ELF, but this is the next big step, IMHO.

Congratulations! You are the one-millionth user to log into our system. If there's anything special we can do for you, anything at all, don't hesitate to ask!

Working...