Portability Is Reliability
evan.nemerson.com
Portability Is Reliability
1–10 of 26 posts
Re: Portability Is Reliability
#2I don't find the defence in depth approach appealing, because it's never going to get you to 100% reliability. Rather than adding six swiss-cheese layers and hoping the holes don't line up, it would be better to spend more time and effort on a single really solid layer.
For the same reason, I don't find the argument for fixing bugs in C codebases at all compelling (at least if we're talking about "micro" bugs rather than overall architecture issues that might carry over to a future rewrite). Sure, there's a lot of C out there. Sure, a lot of the bugs in that C code are findable. But so what? However many bugs you uncover, you're unlikely to find them all, and even if you did then how would you know? So isn't fixing bugs in existing C codebases just throwing good money after bad? You know you're inevitably going to have to rewrite it all eventually anyway.
Re: Portability Is Reliability
#3Eric Raymond, not Linus Torvalds, said the "given enough eyeballs" quote. Unfortunately there aren't enough eyeballs, so bugs linger for years anyway.
Re: Portability Is Reliability
#4Focusing all your might on a single platform can give you reliability and even better performance, and is less work.
Focusing on portability gives you a set of abstractions to build upon, that will take your time, reduce performance often, and limit your capabilities. But... it can also make you have a better mental problem of the problem you're solving, and allow you to move faster when underlying details change.
Like everything, it has ups and downs, I think.
Re: Portability Is Reliability
#5I don't find the defence in depth approach appealing, because it's never going to get you to 100% reliability. Rather than adding six swiss-cheese layers and hoping the holes don't line up, it would be better to spend more time and effort on a single really solid layer. For the same reason, I don't find the argument for fixing bugs in C codebases at all compelling (at least if we're talking about "micro" bugs rather…
I don't understand. Wouldn't it mean that you leave software used by millions of users to rot while you rewrite in your newer better stack? Not fixing bugs, holes and regressions? How would that make things better? Maybe you have something else in mind, but I think you failed to conveyed it here.
Also with newer stack you will still do a bunch of logic errors, that you managed to fix in you old ugly C code base. You gonna repeat that the hard way.
Don't get me wrong, I'm not against rewrites. But not fixing old code, until you are done with next version is irresponsible.
In a way I think we already live in such a world. Companies are throwing a product, then they are doing minimal maintenance until they newer better version will come. When it finally comes it may have a few good qualities, but it is never without hindrance to users.
Re: Portability Is Reliability
#6I don't find the defence in depth approach appealing, because it's never going to get you to 100% reliability. Rather than adding six swiss-cheese layers and hoping the holes don't line up, it would be better to spend more time and effort on a single really solid layer. For the same reason, I don't find the argument for fixing bugs in C codebases at all compelling (at least if we're talking about "micro" bugs rather…
I don't understand. Wouldn't it mean that you leave software used by millions of users to rot while you rewrite in your newer better stack? Not fixing bugs, holes and regressions? How would that make things better? Maybe you have something else in mind, but I think you failed to conveyed it here. Also with newer stack you will still do a bunch of logic errors, that you managed to fix in you old ugly C code base. You…
> Wouldn't it mean that you leave software used by millions of users to rot while you rewrite in your newer better stack? Not fixing bugs, holes and regressions? How would that make things better?
Whatever you do, the software will be full of bugs and holes until you rewrite it. So I think the users are best served by prioritising the actual rewrite rather than papering over the cracks.
> Also with newer stack you will still do a bunch of logic errors, that you managed to fix in you old ugly C code base. You gonna repeat that the hard way.
Not so in my experience. The logic is what you port, so you end up with the same logic. But the "micro" bugs disappear, because that part is different between languages.
Re: Portability Is Reliability
#7I don't find the defence in depth approach appealing, because it's never going to get you to 100% reliability. Rather than adding six swiss-cheese layers and hoping the holes don't line up, it would be better to spend more time and effort on a single really solid layer. For the same reason, I don't find the argument for fixing bugs in C codebases at all compelling (at least if we're talking about "micro" bugs rather…
> However many bugs you uncover, you're unlikely to find them all
It is not specific to C/C++ - in any language there will be some bugs you're unlikely to find (before they are reported).
> So isn't fixing bugs in existing C codebases just throwing good money after bad? You know you're inevitably going to have to rewrite it all eventually anyway
If it took many years to write a big C codebase, then a rewrite likely will take significant time too (or you'll drop many useful features and/or introduce new bugs). And most software project take more time than anticipated, rewrites is not an exception here. Isn't is a waste of money too, just another kind?
Re: Portability Is Reliability
#8Nooo node/electron should be enough for everyone.
Before node/electron, that was msvc.
There is also the occasional article stating that people with multiplatform development experience are simply better at debugging their code.
Re: Portability Is Reliability
#9I don't find the defence in depth approach appealing, because it's never going to get you to 100% reliability. Rather than adding six swiss-cheese layers and hoping the holes don't line up, it would be better to spend more time and effort on a single really solid layer. For the same reason, I don't find the argument for fixing bugs in C codebases at all compelling (at least if we're talking about "micro" bugs rather…
> However many bugs you uncover, you're unlikely to find them all It is not specific to C/C++ - in any language there will be some bugs you're unlikely to find (before they are reported). > So isn't fixing bugs in existing C codebases just throwing good money after bad? You know you're inevitably going to have to rewrite it all eventually anyway If it took many years to write a big C codebase, then a rewrite likely w…
> It is not specific to C/C++ - in any language there will be some bugs you're unlikely to find (before they are reported).
Perhaps (though frankly I doubt it). But at the very least it's very possible to avoid the "everything is a security bug by default" phenomenon of C/C++ undefined behaviour; your program may still crash occasionally, but a clean crash is relatively benign compared to security bugs or even just silent data corruption.
> If it took many years to write a big C codebase, then a rewrite likely will take significant time too (or you'll drop many useful features and/or introduce new bugs). And most software project take more time than anticipated, rewrites is not an exception here. Isn't is a waste of money too, just another kind?
If a rewrite is necessary, then the sooner you start the sooner you'll finish. I'm coming from a view that a) C/C++ code is always insecure and cannot be made secure b) as exploitation improves along with everything else, running insecure code will become increasingly untenable. You could disagree with either premise.
Re: Portability Is Reliability
#10Portability is complexity. Complexity is diametrically opposed to reliability.