Slashdot Mirror

← Back to Stories (view on slashdot.org)

ESR's New Kernel Config Tool

Posted by timothy on from the built-in-validity-checking dept.

Mark Bainter writes: "ESR has released CML2 the new config tool for the linux kernel. I'm sure the softies amoung us will love it, but frankly I think it sucks. Half the things listed as features I'd list as bug reports. A few "highlights": In CML2 it will automatically select and deselect required features related to the option you are manipulating. Options don't appear at all when not needed instead of being greyed out, and the language has been changed to declaritive instead of imperitive. And last but certainly not least, it runs on Python." Interesting discussion on the current kernel traffic about the new tool, too -- but it sounds mostly positive. Thank you, Eric, for bringing arcane kernel issues closer to earthlings.

9 comments

  1. Re:make menuconfig has the same 'feature' by Anonymous Coward · · Score: 1
    An example that comes to mind is the bt848 device, which isn't listed until i2c is enabled. Both are on different pages, and there is no indication that one will enable the other

    This is open source. You know what you can do now.

  2. Re:Easy on the Vitrol by Anonymous Coward · · Score: 2
    If I want to compile feature (a) into my kernel which requires feature (b) I don't want it to automatically select and unselect feature b for me. I may not /want/ feature b

    what would you like to happen to feature (b) when you select feature (a) in make menuconfig (or whatever)? should the make config complete happily, and then the compile fail? or (what i think you think) - should it tell you what dependencies exist and are altered by your selection?

    This doesn't belong in

    make config

    this belongs in

    make configButIKnowWhatImDoing

    If you know enough to care about what dependencies exist, but you don't know what they are, make configButIKnowWhatImDoing isn't right, it's more likely to be make

    configButIKnowVaguelyWhatImDoing

    Either way (or any other way for that matter), if you don't like it, tell the man why (on lkml, not /.) AND suggest how to make it better.

    This post brough to you by a spork hater, 8 cans of stella, 1/2 litre vodka, and 100mg prozac - don't try this at home.

  3. Easy on the Vitrol by Anonymous Coward · · Score: 5
    ESR has released CML2 the new config tool for the linux kernel. I'm sure the softies amoung us will love it, but frankly I think it sucks.

    If you think it sucks so much, why bother to post about it to Slashdot?

    What you probably should have done is write up a review of it, and post a link to that to Slashdot, along with the link to the tool. As it stands now, Mark's one paragraph blurb is pointless; it doesn't give nearly enough detail to be classified as a review.

    And timothy, it may be wise to exersize some editiorial control. Just because someone wrote a tirade doesn't mean you have to publish *all* of it.

    A better blurb:

    Mark Bainter writes: "ESR has released CML2 the new config tool for the linux kernel. ... A few "highlights": In CML2 it will automatically select and deselect required features related to the option you are manipulating. Options don't appear at all when not needed instead of being greyed out, and the language has been changed to declaritive instead of imperitive." Mark doesn't seem to like it much, but there is interesting discussion on the current kernel traffic about the new tool -- mostly positive. Thank you, Eric, for bringing arcana kernel issues closer to earthlings.

    In short, drop the personal attacks ("the softies"), the pointless bashing of the tool ("it sucks"), and the language war flamebait ("And last but certainly not least, it runs on Python.").

    It's a Slashdot worthy story, but not a Slashdot worthy writeup.

    --
    Zen Koan of the day: Slashdot stories suck because Slashdot readers post them.

    1. Re:Easy on the Vitrol by Mark+Bainter · · Score: 1

      Either way (or any other way for that matter), if you don't like it, tell the man why (on lkml, not /.) AND suggest how to make it better.

      Because I know it won't make any difference. Nothing I could say would ever make a whit of difference in this project. Eric wants to dumb down the interface, and he's going to do it. Linus, for whatever reason, has gone a long with it.

      So why bother posting at all?

      I guess I do it for the few of us who still care. And at least partially I do it so that I don't get swept along with the tide.

      Frankly, I don't think there should be any mode but IKnowWhatI'm Doing. If you don't know what you are doing you shouldn't be compiling the kernel. It isn't that hard to learn to know what you are doing.

      --
      "No nation could preserve its freedom in the midst of continual warfare."
      --James Madison
    2. Re:Easy on the Vitrol by Mark+Bainter · · Score: 1

      I disagree. How often do you "make config" instead of "make menuconfig"/"make xconfig" ? I don't use "make config" anymore. Well, being for "softies" is exactly the critique that was done to projects for menu/graphical tools.

      Yeah, but that's a dumb argument imo. Just having a graphical or semigraphical interface doesn't make it "for softies". I specifically use that term in regards to software that protects the user from him/herself to their detriment.

      --
      "No nation could preserve its freedom in the midst of continual warfare."
      --James Madison
    3. Re:Easy on the Vitrol by Mark+Bainter · · Score: 1

      Whoops. Forgot to address one of your points there. I could accept it informing the user what it depends on. But it's the users responsibility to select it. But I'd want it somewhere like help or in the summary text, not in a popup. When I'm flying through a kernel config I do not want to deal with a hundred popup windows.

      And yes, if you blow it, the compile fails and you fix it. Easy.

      --
      "No nation could preserve its freedom in the midst of continual warfare."
      --James Madison
    4. Re:Easy on the Vitrol by Mark+Bainter · · Score: 4

      It will probably come as a surprise but I actually agree with you. I kind of shot it off not actually expecting to see it posted. Just an extension of Murphy's law I guess. If I spend time composing a good post, it gets rejected out of hand. If I throw up a blurb and don't bother to reread it gets accepted. -roll-

      Why post it if I thought it was going to get rejected? Who knows. I was tired and more than a little irritated and wrote it in that state. Never a good idea. I posted when I didn't like it because it's a pretty critical part of the kernel, and thus it is news that people should hear about.

      A few more extensive notes:

      a) Greying out options is a bad thing imo because it makes it more difficult to see the kernel as a whole. When a new kernel is released I go through the release notes and look at the new options in the config tool. Greying them out unless an option they depend on/etc is clicked will make this more difficult at best.

      I think this, coupled with the other "features" to make it easier to use do not make things better, but rather set us a ways down the path to user friendliness at the expense of flexibility and power. I use linux because I like the fact that I can do what I want even if the people who wrote it didn't anticipate my using it in that fashion. If I want to compile feature (a) into my kernel which requires feature (b) I don't want it to automatically select and unselect feature b for me. I may not /want/ feature b. Plus, I have yet to see this even implemented so it works in a sane fashion. The install tools for most every major distribution (except slackware, and I think debian) are a perfect example of this (in the package selection stages)

      softies was not a personal attack. I think those are the people who will most appreciate this tool, and from what Eric said it's pretty much who it's aimed at. People who want a few clicks to build everything and not have to see the internals and not have to really know what they are doing and to have the tool protect them from themselves. (Sound familiar at all)

      I wasn't pointlessly bashing the tool. I was giving my evaluation of it. I think it sucks. I can't believe this is something that the serious linux users wants today. And if it is, then it is very sad indeed. I just don't agree with Eric's whole premise for doing this. (That being that he realized the kernel is too hard to compile) That's just baloney. I have yet to meet someone who thought the linux kernel was hard to compile. I used to respect Eric. Probably mostly because he provided a nice check for some of the more outrageous views Stallman and his crew carry. But lately I've lost most of that respect. And not just from this.

      And my comment on python had nothing to do with starting a language war. I am not a language bigot. I'm not even an os bigot. I just wish we'd stop adding so many freaking dependencies to everything. I and others I know have taken a lot of time to scrape out the stuff we don't use from our linux installs. Most notably things like Python and Info. Not that python doesn't have it's good points, but I never write in it, and so I have no use for it, so i don't want it on my box. There was really no good reason for redoing it in Python afaik other than that he wanted to. (He said it was because it was it was compileable, but so is C and so is perl so that's bogus. And the way he mentioned it seemed more like an afterthought in response to complaints about having to have another tool installed than anything)

      Alan Cox was quoted as saying it wasn't a big deal since you only had to have it on the build box, but I doubt that many of us have enough boxes laying around to have one for building packages for all the others, so this is hardly a valid point. (No offense Alan. ;-)

      I'm out of time. (Darn.) Hope this is more informative and well reasoned than the post was. ;-)

      --
      "No nation could preserve its freedom in the midst of continual warfare."
      --James Madison
  4. make menuconfig has the same 'feature' by Snowfox · · Score: 3
    Also with 'make menuconfig' - some modules aren't even listed if other modules/options aren't selected.

    An example that comes to mind is the bt848 device, which isn't listed until i2c is enabled. Both are on different pages, and there is no indication that one will enable the other.

    ---
    My opinions are mine.

  5. Search facility; Office 2000 menus? by leighklotz · · Score: 5

    It sounds like some of the concerns about greyed out vs. invisible options could be alleviated by a good search facility. But being presented with some of the options is an educational experience, and not being able to see "everything" fairly easily could detract from the experience.

    I note that Microsoft in Office 2000 has taken to hiding menu options that a user doesn't use, and some people like it, but some don't. For me it's the same issue -- it's hard to discover things that you never see.