Freigeben über

10,000 or 200?

  • Artikel

About a year and half ago I asked "Is your job easier or harder with 10,000 components?". Let's surface this question again and do some brainstorming.

I agree with most of you that 1,000 feature components and 9,000 driver components does generate a lot of noise for you to sift through at times. And given that a lot of the CoreOS components and other typical low level features are in virtually all of your devices anyways, having the granularity of 1,000 components sometimes doesn't make sense.

What I've heard from a lot of you over the years is that maybe it would make sense if we did something along the lines of grouping features together that didn't have a lot of dependencies on *other* feature groups.

For instance, instead of having several dozen components that comprise the Audio stack, why not just group them together and call it the "Audio Feature Component"; it would include everything from Kernel Streaming, Kernel Audio Support, Audio Codecs, Stream Buffer Engine, Legacy Audio Drivers, etc...It would almost be impossible to not have a good working audio stack on your device this way which greatly increases your level of confidence.

The downside of course that there may be a few among you that are so hard core and low level that you *want* to tweak and hack away at the stack so your device only contains the files and keys that are absolutely necessary to the function of your device's scenario. For those developers, the concept of feature groups may not be as attractive, but your device bring-up time would probably be reduced.

So again, I pose the question again and add a new question:

1. Is your life as an embedded developer better off with say 1,000 windows feature components as it is today, or better off with ~100-200 windows feature groups?

2. Are you willing to accept some footprint hit to guarantee that the feature groups were well componentized? For instance, perhaps a new Internet Explorer Group includes all of it's optional features and it increases footprint from say 20MB to 50MB, but it did *not* depend on many dozens of other components or groups.

Please leave comments, any pros/cons you see in this? Any features you're particularly fond of and would like to see grouped together as listed above?

- Andy

Comments

  • Anonymous
    December 04, 2006
    The comment has been removed

  • Anonymous
    December 04, 2006
    Andy Allred is asking an interesting question over on the XPE blog - Windows XP Embedded SP2 Feature

  • Anonymous
    December 04, 2006
    The comment has been removed

  • Anonymous
    December 04, 2006
    The comment has been removed

  • Anonymous
    December 04, 2006
    The comment has been removed

  • Anonymous
    December 04, 2006
    Whatever the outcome, the requirement to be able to tweak a system to save that odd 500k in size is a mandatory one. You will never be able to make the construction of a working image foolproof, and I think that reducing the amount of understanding required to build an image will ultimately lead to more of those hard to find issues popping up for the average developer, rather than the opposite.

  • Anonymous
    December 04, 2006
    The comment has been removed

  • Anonymous
    December 05, 2006
    I vote for doing both.

  • Anonymous
    December 06, 2006
    The comment has been removed

  • Anonymous
    December 06, 2006
    The comment has been removed

  • Anonymous
    December 06, 2006
    The comment has been removed

  • Anonymous
    December 08, 2006
    The comment has been removed