On Wed, Aug 19, 2015 at 07:08:25PM +0100, Rainer Weikusat wrote: > Steve Litt <sl...@troubleshooters.com> writes: > > On Wed, 19 Aug 2015 18:25:45 +0100 > > Rainer Weikusat <rainerweiku...@virginmedia.com> wrote: > >> Edward Bartolo <edb...@gmail.com> writes: > >> > I am not assuming anything and understand the risks of buffer > >> > overflows. The first step I am taking is to make the code function. > >> > The second step is further debug it until it behaves properly and > >> > the third step is to correct any potential security issues. > >> > >> Realistically, the first step is 'make the code function', the second > >> step is 'graduate from university based on your thesis' and the 3rd > >> was called 'heartbleed', IOW, that's not going to happen in this way. > >> If you're doing string processing in C, try to do it correctly from > >> the start. That's much easier than retrofitting proper length/ size > >> handling onto some working code. > > > > LOL, hey guys, cut Edward some slack. He whipped this up in one day, > > when the rest of us, especially I, were sitting on our hands *with > > respect to a Wifi tool*. > > I was commenting on the code and the methodology and not on him: As I > tried to demonstrate with the example I posted, it's not really > difficult to get it right from the start. > > [...] > > > In The Cathedral and the Bizaar, Eric Raymond says the following: > > > > ================================================================== > > When you start community-building, what you need to be able to present > > is a plausible promise. Your program doesn't have to work particularly > > well. It can be crude, buggy, incomplete and poorly documented. What it > > must not fail to do is (a) run, and (b) convince potential > > co-developers that it can be evolved into something really neat in the > > forseeable future. > > ================================================================== > > In "The Cathedral of the Bizarre" (love this typo), it usually works > like this: > > 1. The code is buggy (for a certain definition of buggy) because whoever > originally wrote it couldn't be bothered to deal with the > issue. Because of this, should you be forced to fix it, don't bother > sharing the fix with the author: If he had cared about that, you > wouldn't have had to fix it and, and since he doesn't, he (at best) > won't care about you fix, anyway. > > 2. The code lacks features because none of the people who control it > were interested in them. In case you add some, don't bother trying to > share you changes: The people who control the code won't exactly be > happy when others suddenly try to exercise some control, too and > since they don't need the feature, they (at best) won't care. Should > someone sufficiently important need it in future, they'll reimplement > it. > > Things may have worked differently in the early days of Linux (the > project) but that's because Linus Torvalds is an outstanding project > manager (among other things) but since Linux turned into a billion > dollar business, it stopped working in this way a long time ago.
Isn't it our calling at devuan to bring those days back? I know, it's probably tilting at windmills. -- hendrik _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng