On Wed, Aug 19, 2015 at 07:08:25PM +0100, Rainer Weikusat wrote:
> Steve Litt <slitt@???> writes:
> > On Wed, 19 Aug 2015 18:25:45 +0100
> > Rainer Weikusat <rainerweikusat@???> wrote:
> >> Edward Bartolo <edbarx@???> 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
::
Re: [DNG] Systemd Shims
