But I agree with the previously-made point about interface testing. You need real (non-CS) people for that.
Definitely. There's not much reason for programmers to be good at this, as it demands its own skills and experience and is mostly orthogonal to correctness testing.
A developer can be the best person to test his code. But only if he truly respects the value of testing. This is a respect that must be cultivated in most people. Unfortunately, most projects (volunteer or commercial) fail to do this. Commercial projects generally forsake the effort and dedicate a different team to testing. Most (not all) volunteer projects simply forsake it (but ESR's bazaar priciples can make up for this lapse).
I don't disagree that even a consciencious programmer can be blind to his own mistakes. However, if he cares about quality, he will also be the most acutely aware of the weaknesses and possible problem areas in his code. This should let him target his testing to maximum effect. A dedicated tester on the other hand will basically shoot at random parts of the code.
Don't get me wrong--I'm glad my company has testers. They are more cost-effective at catching many bugs, especially those that only show up when all the pieces are put together. But they should only start testing after developers do their own testing and debugging. Otherwise, their time is wasted reproducing, confirming, isolating, and reproducing simple bugs that the developer could diagnose and fix in minutes.
If there can only be one tester, it should be the developer, if he is consciencious.
I can't speak to everyone's philosophy, but in the GNU orthodoxy, this is horribly inaccurate. The GNU Manifesto is perhaps the bible; copyleft (and thus the GPL) is a hack of copyright law that assists the progress of the GNU project. RMS has stated that GNU and the free software movement would be harmed but hardly crippled if the GPL were not enforcible.
Think about it: copyright is about restricting copying, and GNU is fundamentally about promoting copying. The fact that the first can be used in the service of the second is a cool trick, but that's all it is. RMS would be happy if copyright didn't apply to software at all.
A possibility that hasn't been mentioned yet is: dpkg supports three levels of dependency: depends, recommends, and suggests. apt only tries to satisfy the depends dependencies, whereas dselect will try to satisfy the depends and the recommends dependencies.
I'm not sure that this fits your problem description, though.
Let me clarify (to allay a few of the flames) that I think all of the things on my list should be doable while I'm deciding what to install, preferably without downloading the whole package. I know I could do most items by writing a script to download the new package, possibly unpack it into a temp directory, and poke around. But imagine if you had to do this just to read the description of the package. I'm proposing that all of the things I list be as readily available as the package description.
Your answers are very superficial. I use Debian, so I know about all the things you mention. They all fall short.
security.debian.org does make it possible to install only security fixes on a stable system. That's an important but very limited case. It doesn't help if I replace security with any other criterion. Moreover, what if I'm running unstable? I often do this, but there are still times when I don't want to risk installing any upgrades but critical ones.
hold is a very blunt instrument. For example, if I install version 1 and put the package on hold, I will get alerted by deselect when version 2 comes out (ie, it will appear in the "Updated" section"), but if I choose not to upgrade, I won't get any new indication when version 3 comes out. I have to remember that version 2 was the last version I considered.
searchable package descriptions are nice, and I use apt-cache search all the time, but I often miss packages by choosing the wrong search strings. A more structured way of describing package functionality would be better.
Debian stable does not contain only well-integrated, well-tested packages. If you think so, you're either horribly biased or smoking something. Think about GNOME in slink. Or the many orphaned packages in any stable release. Or all the random little programs used by almost nobody and packaged by novice Debian developers.
i think M$ makes an operating system that you might like to check out.
Really, I thought they made Windows?
I see half of linux users bitching that they want it all (these are mostly new-school linux users that i've seen) and i see another half that want's nothing more than a kernel and a keyboard.
Trust me, I'm not new-school. But I think that anyone satisfied with the current state of Linux is badly lacking in imagination or ambition.
I really don't want to see linux turn into an OS where you click the do-everything button and all of the sudden you're set to do whatever it is that you wanted.
Did I say anything about buttons? Would it be better if I'd said I wanted to pipe the changelog to grep? Approve or reject upgrades with scheme code? Run diff3 --merge on the current, old, and new config files, starting $EDITOR on the result to resolve conflicts while popping up the new man page for the config file in another xterm? You can't do any of these things now because the information's not there, and the infrastructure's not there. Not because there are no buttons.
Please don't assume that usability means baby talk.
All of the package management systems duck the hard problems of creating a user-centered system management tool. Why can't I
ask why a new version of a package was released?
see a list of changes between old and new versions?
tell the system to apply only security or high-priority fixes?
tell the system to automatically process all updates except those involving specified packages, which I want to approve on a case-by-case basis?
tell the system never to upgrade packages that require upgrades of packages used by other software (eg, libraries)?
ask for packages that will help me convert GIF files to PNG?
ask for only packages targeted at beginners?
ask for only well-integrated, well-tested packages?
get reviews of a package?
find out how to get started using a package?
begin browsing the documentation for a package before approving a full installation?
have some help in configuration updates?
This is an abbreviated list, but I've wished for some variant of each many times.
Note I acknowledge that these are hard problems. I don't expect them to get implemented overnight. The problem is, I don't see anyone even trying. (Possibly Helix Code, it's too soon to be sure; at any rate, they will need the help of the distribution maintainers to go all the way.) Someone could make a great contribution by seriously studying what users need to take control of their systems and designing a solution, not just looking for the next hack.
I use Debian personally. I think dpkg+apt has more cool hacks than rpm+autorpm (or whatever), but I don't think it's significantly further in the big picture. I do think it has more possibilities, given its philosophy and development community.
Finally, I know some moron will jump up saying that rpm wasn't meant to do all this, and its developers intentionally limit its scope. I don't care whether rpm solves the problem, or a system build around rpm solves it; I do care that the problem isn't being addressed.
I'm pretty sure that whatever contract you have with your employer requires you to cooperate in protecting the company's "IP" (I don't have mine with me to check, but it says something like this). This absolutely does not oblige you to sign something you believe is false.
This helps you only if you believe that the patent application does not fulfill the relevant legal requirements. Unfortunately, it does not help you if you just feel that the legal requirements are wrong. In that case, the patent application is technically truthful, and it is probably your obligation to sign your name to this.
However, you do have some opportunities to find holes in the application. If you find any of the claims obvious or non-original, write up a short case and require that it be addressed before you will sign. If you can find prior art related to the patent claims, demand that it be included in the application. Patent applications may not knowingly omit prior art, and applicants are required to search for prior art, so this behavior is entirely legitimate.
I'm gonna have to play devils advocate here, because I see lots and lots of references to how awful Windows NT's security is, yet no specific examples.
You really should read BUGTRAQ (or, if you can put up with the somewhat lower level of discourse, NTBUGTRAQ). I don't know NT well, but I believe that this recent vulnerability gives a local user admin-level privilege. For remote root, the IIS buffer overflow found by EEye some months ago comes to mind.
Either you didn't read the article, or you didn't understand it.
Brown Orifice exists because the people who understood the different
components did not or could not see how the interaction of these various
pieces could cause trouble.
If you've followed BUGTRAQ lately, you'd know that this malady seriously affects Windows systems, and that examples have included Microsoft-Microsoft, Microsoft-third party, and third party-third party component interactions.
It it too hard for you to conceive that the particular case (Netscape 4) is but an example of a general theme? If so, you should probably refrain from programming or entering any field that requires abstract thought.
The evidence from the MS world is that buffer overflows are the _least_ of
your worries in a component based environment. Complete inability to build
a coherent security model combined with people who wave their arms around when
asked hard questions about it are most of the problem.
Nobody in the windows world is much into buffer overflows right now, you dont
need them to tear apart a windows system. There's a lesson there for gnome.
This idea is good, but it doesn't meet the basic needs of translation: grammar differences might require that the %d and %s be switched.
That's what I feared until I read the printf(3) manual carefully. Try printf("%2$d - %1$d", 1, 2);. I'm not sure how portable this is, though. I'm using glibc 2.1.3.
I say just don't use printf style format strings at all.:-)
The thing is, using structured templates + "fill-ins" for makes great sense for message customization and in particular localization. Otherwise, your translators have to modify code! In that case, you have no hope of (eg) preventing a malicious translator from doing nasty things. Whereas if your template format and API are properly designed, the template is effectively a sandbox for the translator.
I won't claim that the printf template format is great, but it does the job. All you need is to tighten up the API to prevent abuse. (In C, this is necessarily ugly:-/)
The bad coding practice is not realizing that C format strings are morally equivalent to arbitrary code, and distrusting them accordingly. For code running without privilege, there is no problem at all, but code running with privilege must ensure that format strings come from a trusted source.
If you want to go to the real root of the problem, the bad practice is not using type-safe string formating APIs. It seems that a simple one would simply require an extra "template" format string that must be known at compile time (so the compiler can check that the right number of arguments are passed), and that is used to validate the real format string at run time. Then i18nized code would look like printf2("%d%s", _("You have %d %s(s)"), qty, name)
(where _() is the conventinal dictionary lookup macro). Then if the joker gives you a format string that accesses the first fill-in argument as a string, or access a third fill-in argument at all, there is a run-time failure.
security is process, not technology
on
GPG vs. PGP?
·
· Score: 3
Barring egregious mistakes in the software, your overall security is dominated not by what's inside, but by how you use it. That said, I think the important considerations may be:
How easy is it to use properly? Does it take a lot of configuration to get right? Does it err on the side of paranoia? Is there a front-end that makes it easy to do the right thing?
How good is the documentation? Does it recommend good practices and explain why they're right?
How's the support? Where can you get your questions answered?
That's a cute haiku, but Perl vs. Python isn't really worth it. Both languages seek to occupy similar niches, but they do it with such different styles that neither is much of a threat to the other. Both are free, both have nice communities, and, despite a few quirks on either side (eg, whitespace sensitivity in Python and magic variables in Perl), both have sufficient support for solid engineering of a wide range of programs.
Perl and Python advocates should direct their spleen at scripting languages that fail to support complicated programs (eg TCL, Visual Basic, or even perl 4 style Perl), and at the misguided application of low-level languages to scripting tasks (eg writing simple applets and dynamic web pages with C and Java).
These are, IMO, causes worth promoting for the sake of better software.
But without comments, I must spend an hour or two reviewing the code, just to get a rough understanding of how it all works. Pardon me, but that is time wasted.
No, it's code review, and most people would agree that most code doesn't get enough review, so it's hardly time wasted. Plus, now you have a deeper understanding of the code. Maybe not your top priority an the time, but a long-term benefit.
Further, do you know how much it sucks to maintain code that has had many changes made by people who looked at the code just long enough to make their one change?
Quality comments are a wondrous thing: comments that provide a roadmap to the code, an overview of the data structures and how they fit together, clear explanations of the subtle operations, and warnings of the pitfalls. But quality comments take more thought to write and are more likely to fall out-of-date (since they're high level and don't map directly to the bits of code that might be changed), so they require talented and consciencious programmers. Most people I've known who have been told to comment heavily leave poor comments, which I feel are worse than useless as I argued before.
I've heard time and time again that good code should document itself. That's purest bull.
It's bull that all good code should document itself. I claim that a lot of it should. (Maybe not even most; it's hard to measure code space.)
I'm aghast that anyone would be advocating less comments in code.
I'm not advocating fewer comments, per se. I'm suggesting that emphasizing comment quantity and uniformity is not the best route to overall better software. The fact that it seems like a good idea at first blush makes it more insidious.
In my coding experience, there is nothing more annoying than excessive comments--with the possible exception of wrong comments. And therein lie the perils of your suggestions.
Wrong comments are an obvious plague, especially in free software where contributers may not have much stake in long-term maintenance. The saying goes: if the code and comments disagree, both are probably wrong. Excessive comments are a more subtle issue, at very least because "excessive" is a judgement call. One thing is clear: with more comments, you can fit less code on the screen or page, which is a penalty not to be ignored (I think this is part of the reason for the productivity of high-level languages).
More subjectively, I tend to find that people who write copious comments can't express their ideas concisely, or aren't clever enough to express their meaning directly in code. In many cases, I would rather the author work on code quality than commenting.
When working with other people's code, there is nothing I prefer over code that is so clear, concise, and well organized that I don't notice a lack of comments. Unfortunately, this isn't possible for all problems. I recall an anecdote from Donald Knuth in which he claims he would have been unable to successfully implement an algorithm without literate programming, and I believe it.
However, I was hacking on a piece of free software (vgetty) this weekend, and when I read this article, I realized I couldn't remember whether the code had many comments. I just checked, and found that (the parts I worked with) did not (although the debug output was a partial substitute). But I never missed them, because the code just made sense internally and fit into the larger system in an obvious way.
One final point. At advogato, there is a discussion of how to encourage more contribution to existing projects, instead new projects. What I think was missed there is that an influx of casual novice programmers isn't necessarily a boon to most projects (bug reports and fixes, maybe, new content, less likely). Linux is good largely because it is optimized for sharp programmers who are willing to study the design (and the development process). This doesn't mean eschewing documentation (the in-line documentation system in 2.4 is encouraging), it means placing less value on beginner-level documentation. This is like all things a trade-off, and I think a good one. Ability to understand kernel design is a good test of who I want futzing with my kernel!
Better yet is being able to build those embedded systems using the exact same system you use on your desktop.
The synergies of dealing with one system for multiple purposes are huge. The same lesson that has been learned in IC's and microprossors will be learned in kernels as well: make something that is good enough over a range of applications, then focus all your energy on that technology, and pretty soon it will beat specialized technologies at their own games.
You don't need to #ifdef and compile differnt parts to make it fit in your PDA. Simply only run the parts of the system you need to run. This is the true advantage of the microkernel.
This, however, is bullshit. Picking which parts to run can be done as easily with Linux kernel modules as with microkernel servers. I bet that the parts of Linux that can't be modularized are pretty comparable to the core QNX microkernel. (Yes, QNX is still smaller, because it's optimized in that direction.)
It amazes me that, for all the emphasis the point receives, a participant in this discussion doesn't understand the difference between free software and free beer. It seems from his diatribe that the latter is all he can comprehend, while it is of secondary importance to the GNU and GNOME projects. It's painful to hear him boast righteously that he won't make much money from his KDE book, while accusing GNU (which has sold software since its inception) of hypocracy for cooperating with corporations on the terms of free software.
Slashdot Mirror
Definitely. There's not much reason for programmers to be good at this, as it demands its own skills and experience and is mostly orthogonal to correctness testing.
A developer can be the best person to test his code. But only if he truly respects the value of testing. This is a respect that must be cultivated in most people. Unfortunately, most projects (volunteer or commercial) fail to do this. Commercial projects generally forsake the effort and dedicate a different team to testing. Most (not all) volunteer projects simply forsake it (but ESR's bazaar priciples can make up for this lapse).
I don't disagree that even a consciencious programmer can be blind to his own mistakes. However, if he cares about quality, he will also be the most acutely aware of the weaknesses and possible problem areas in his code. This should let him target his testing to maximum effect. A dedicated tester on the other hand will basically shoot at random parts of the code.
Don't get me wrong--I'm glad my company has testers. They are more cost-effective at catching many bugs, especially those that only show up when all the pieces are put together. But they should only start testing after developers do their own testing and debugging. Otherwise, their time is wasted reproducing, confirming, isolating, and reproducing simple bugs that the developer could diagnose and fix in minutes.
If there can only be one tester, it should be the developer, if he is consciencious.
I can't speak to everyone's philosophy, but in the GNU orthodoxy, this is horribly inaccurate. The GNU Manifesto is perhaps the bible; copyleft (and thus the GPL) is a hack of copyright law that assists the progress of the GNU project. RMS has stated that GNU and the free software movement would be harmed but hardly crippled if the GPL were not enforcible.
Think about it: copyright is about restricting copying, and GNU is fundamentally about promoting copying. The fact that the first can be used in the service of the second is a cool trick, but that's all it is. RMS would be happy if copyright didn't apply to software at all.
A possibility that hasn't been mentioned yet is: dpkg supports three levels of dependency: depends, recommends, and suggests. apt only tries to satisfy the depends dependencies, whereas dselect will try to satisfy the depends and the recommends dependencies.
I'm not sure that this fits your problem description, though.
Let me clarify (to allay a few of the flames) that I think all of the things on my list should be doable while I'm deciding what to install, preferably without downloading the whole package. I know I could do most items by writing a script to download the new package, possibly unpack it into a temp directory, and poke around. But imagine if you had to do this just to read the description of the package. I'm proposing that all of the things I list be as readily available as the package description.
Really, I thought they made Windows?
I see half of linux users bitching that they want it all (these are mostly new-school linux users that i've seen) and i see another half that want's nothing more than a kernel and a keyboard.
Trust me, I'm not new-school. But I think that anyone satisfied with the current state of Linux is badly lacking in imagination or ambition.
I really don't want to see linux turn into an OS where you click the do-everything button and all of the sudden you're set to do whatever it is that you wanted.
Did I say anything about buttons? Would it be better if I'd said I wanted to pipe the changelog to grep? Approve or reject upgrades with scheme code? Run diff3 --merge on the current, old, and new config files, starting $EDITOR on the result to resolve conflicts while popping up the new man page for the config file in another xterm? You can't do any of these things now because the information's not there, and the infrastructure's not there. Not because there are no buttons.
Please don't assume that usability means baby talk.
- ask why a new version of a package was released?
- see a list of changes between old and new versions?
- tell the system to apply only security or high-priority fixes?
- tell the system to automatically process all updates except those involving specified packages, which I want to approve on a case-by-case basis?
- tell the system never to upgrade packages that require upgrades of packages used by other software (eg, libraries)?
- ask for packages that will help me convert GIF files to PNG?
- ask for only packages targeted at beginners?
- ask for only well-integrated, well-tested packages?
- get reviews of a package?
- find out how to get started using a package?
- begin browsing the documentation for a package before approving a full installation?
- have some help in configuration updates?
This is an abbreviated list, but I've wished for some variant of each many times.Note I acknowledge that these are hard problems. I don't expect them to get implemented overnight. The problem is, I don't see anyone even trying. (Possibly Helix Code, it's too soon to be sure; at any rate, they will need the help of the distribution maintainers to go all the way.) Someone could make a great contribution by seriously studying what users need to take control of their systems and designing a solution, not just looking for the next hack.
I use Debian personally. I think dpkg+apt has more cool hacks than rpm+autorpm (or whatever), but I don't think it's significantly further in the big picture. I do think it has more possibilities, given its philosophy and development community.
Finally, I know some moron will jump up saying that rpm wasn't meant to do all this, and its developers intentionally limit its scope. I don't care whether rpm solves the problem, or a system build around rpm solves it; I do care that the problem isn't being addressed.
This helps you only if you believe that the patent application does not fulfill the relevant legal requirements. Unfortunately, it does not help you if you just feel that the legal requirements are wrong. In that case, the patent application is technically truthful, and it is probably your obligation to sign your name to this.
However, you do have some opportunities to find holes in the application. If you find any of the claims obvious or non-original, write up a short case and require that it be addressed before you will sign. If you can find prior art related to the patent claims, demand that it be included in the application. Patent applications may not knowingly omit prior art, and applicants are required to search for prior art, so this behavior is entirely legitimate.
IANAL
In case you didn't find it, check out ssleay.txt in the openssl distribution. It's old, but it was very helpful to me.
You really should read BUGTRAQ (or, if you can put up with the somewhat lower level of discourse, NTBUGTRAQ). I don't know NT well, but I believe that this recent vulnerability gives a local user admin-level privilege. For remote root, the IIS buffer overflow found by EEye some months ago comes to mind.
But go browse security focus yourself.
The "turtle does whatever the hell it wants" bug is only present in the "our users are dumber than turtles" release of Microsoft Logo.
Either you didn't read the article, or you didn't understand it.
If you've followed BUGTRAQ lately, you'd know that this malady seriously affects Windows systems, and that examples have included Microsoft-Microsoft, Microsoft-third party, and third party-third party component interactions.
It it too hard for you to conceive that the particular case (Netscape 4) is but an example of a general theme? If so, you should probably refrain from programming or entering any field that requires abstract thought.
http://www.uwsg.iu.e du/hypermail/linux/kernel/0007.3/1305.html
That's what I feared until I read the printf(3) manual carefully. Try printf("%2$d - %1$d", 1, 2);. I'm not sure how portable this is, though. I'm using glibc 2.1.3.
The thing is, using structured templates + "fill-ins" for makes great sense for message customization and in particular localization. Otherwise, your translators have to modify code! In that case, you have no hope of (eg) preventing a malicious translator from doing nasty things. Whereas if your template format and API are properly designed, the template is effectively a sandbox for the translator.
I won't claim that the printf template format is great, but it does the job. All you need is to tighten up the API to prevent abuse. (In C, this is necessarily ugly :-/)
If you want to go to the real root of the problem, the bad practice is not using type-safe string formating APIs. It seems that a simple one would simply require an extra "template" format string that must be known at compile time (so the compiler can check that the right number of arguments are passed), and that is used to validate the real format string at run time. Then i18nized code would look like printf2("%d%s", _("You have %d %s(s)"), qty, name) (where _() is the conventinal dictionary lookup macro). Then if the joker gives you a format string that accesses the first fill-in argument as a string, or access a third fill-in argument at all, there is a run-time failure.
Perl and Python advocates should direct their spleen at scripting languages that fail to support complicated programs (eg TCL, Visual Basic, or even perl 4 style Perl), and at the misguided application of low-level languages to scripting tasks (eg writing simple applets and dynamic web pages with C and Java).
These are, IMO, causes worth promoting for the sake of better software.
PS. This comes from a Perl bigot :-)
No, it's code review, and most people would agree that most code doesn't get enough review, so it's hardly time wasted. Plus, now you have a deeper understanding of the code. Maybe not your top priority an the time, but a long-term benefit.
Further, do you know how much it sucks to maintain code that has had many changes made by people who looked at the code just long enough to make their one change?
Quality comments are a wondrous thing: comments that provide a roadmap to the code, an overview of the data structures and how they fit together, clear explanations of the subtle operations, and warnings of the pitfalls. But quality comments take more thought to write and are more likely to fall out-of-date (since they're high level and don't map directly to the bits of code that might be changed), so they require talented and consciencious programmers. Most people I've known who have been told to comment heavily leave poor comments, which I feel are worse than useless as I argued before.
I've heard time and time again that good code should document itself. That's purest bull.
It's bull that all good code should document itself. I claim that a lot of it should. (Maybe not even most; it's hard to measure code space.)
I'm aghast that anyone would be advocating less comments in code.
I'm not advocating fewer comments, per se. I'm suggesting that emphasizing comment quantity and uniformity is not the best route to overall better software. The fact that it seems like a good idea at first blush makes it more insidious.
Wrong comments are an obvious plague, especially in free software where contributers may not have much stake in long-term maintenance. The saying goes: if the code and comments disagree, both are probably wrong. Excessive comments are a more subtle issue, at very least because "excessive" is a judgement call. One thing is clear: with more comments, you can fit less code on the screen or page, which is a penalty not to be ignored (I think this is part of the reason for the productivity of high-level languages). More subjectively, I tend to find that people who write copious comments can't express their ideas concisely, or aren't clever enough to express their meaning directly in code. In many cases, I would rather the author work on code quality than commenting.
When working with other people's code, there is nothing I prefer over code that is so clear, concise, and well organized that I don't notice a lack of comments. Unfortunately, this isn't possible for all problems. I recall an anecdote from Donald Knuth in which he claims he would have been unable to successfully implement an algorithm without literate programming, and I believe it.
However, I was hacking on a piece of free software (vgetty) this weekend, and when I read this article, I realized I couldn't remember whether the code had many comments. I just checked, and found that (the parts I worked with) did not (although the debug output was a partial substitute). But I never missed them, because the code just made sense internally and fit into the larger system in an obvious way.
One final point. At advogato, there is a discussion of how to encourage more contribution to existing projects, instead new projects. What I think was missed there is that an influx of casual novice programmers isn't necessarily a boon to most projects (bug reports and fixes, maybe, new content, less likely). Linux is good largely because it is optimized for sharp programmers who are willing to study the design (and the development process). This doesn't mean eschewing documentation (the in-line documentation system in 2.4 is encouraging), it means placing less value on beginner-level documentation. This is like all things a trade-off, and I think a good one. Ability to understand kernel design is a good test of who I want futzing with my kernel!
Better yet is being able to build those embedded systems using the exact same system you use on your desktop.
The synergies of dealing with one system for multiple purposes are huge. The same lesson that has been learned in IC's and microprossors will be learned in kernels as well: make something that is good enough over a range of applications, then focus all your energy on that technology, and pretty soon it will beat specialized technologies at their own games.
You don't need to #ifdef and compile differnt parts to make it fit in your PDA. Simply only run the parts of the system you need to run. This is the true advantage of the microkernel.
This, however, is bullshit. Picking which parts to run can be done as easily with Linux kernel modules as with microkernel servers. I bet that the parts of Linux that can't be modularized are pretty comparable to the core QNX microkernel. (Yes, QNX is still smaller, because it's optimized in that direction.)
If I didn't turn on "enable sound" the last time I built a kernel, can I just rebuild sb.o and insert it into the kernel? Nope.
:->
I think you mean, Yup
What problems did you have doing exactly that? (Well, you would also have had to insert the soundcore module.)
The GNU project has dealt with similar issues in regard to bison. Unfortunately, the only documentation I can find at the moment seems to be missing the details: http://www.gnu.org/manual/bi son/html_node/bison_2.html
Poverty does not a saint make.