On 27-Jun-12 13:03, Dejan Lekic wrote:
>
>> accusations with kind of strange proof links BTW all it talks about is
>> "GWAN is not open-source and thus it's bullshit ...".
>> Then it lists some security bugs in old version of GWAN that
>
> I do not know to whom you directed this at - but in my post I did not
> say anything like that.

Am I the only one to see this post:
quote:

I am posting anonymously to protect my identity.

You are right to be suspicious of G-Wan. Regardless of the merits of the software itself, its author is known for his aggressive propaganda of G-Wan, including attempts to cover up serious past security vulnerabilities.

Have a look here to get an understanding of how far this goes:

http://www.wikivs.com/index.php?title=G-WAN_vs_Nginx&action=history

More info:

http://weblambdazero.blogspot.com/2011/09/human-factor.html

/quote

It is simply a personal policy - I do not trust
> closed-source programs, and tend to use a minimal set of them at work
> (typically in Windows environment). On Linux I exclusively use
> open-source applications.

I understand the position but totally disagree on this matter ;)

I do not want to participate in discussions
> about G-Wan's developers, and their way of dealing with the community
> and problems. G-Wan seems a nice product but I will never recommend it
> to anyone. Company I work for will certainly not use it, I can tell you
> that straight away. :)


-- 
Dmitry Olshansky

I am able to see that post.

> Am I the only one to see this post:

On 06/26/2012 06:49 PM, Dejan Lekic wrote:
> xbuf_ncat is a C function, you can't give it a D string just like that -
> you must use std.string.toStringz() ...
>

Yes you can. String literals are zero terminated.

On Tuesday, 26 June 2012 at 20:39:06 UTC, Dmitry Olshansky wrote:
> On 27-Jun-12 00:24, Anonymous wrote:
>> On Tuesday, 26 June 2012 at 16:58:25 UTC, Dejan Lekic wrote:
>>> On Monday, 25 June 2012 at 10:17:27 UTC, P. Lefevre wrote:
>>>> For those interested in web development, GWAN is a VERY fast web
>>>> server (Linux only) which allow development of dynamic pages in C,
>>>> C++, Objective-C, Objective-C++, and D (since january this year) !
>>>>
>>>> see http://gwan.ch/
>>>>
>>>> NB: the perf benchmark on this site seems incredible, but try
>>>> yourself ...
>>>> I did it and I'm convinced.
>>>
>>> I have no intention even to try something that is not open-source
>>> nowadays. It looks nice though, but I will never trust something that
>>> is not open-sourced...
>>
>> I am posting anonymously to protect my identity.
>>
>
> Have to say, that being anonymous *and* posting vague accusations with kind of strange proof links BTW all it talks about is "GWAN is not open-source and thus it's bullshit ...".
> Then it lists some security bugs in old version of GWAN that was then hidden from downloads (and for obvious reasons if you ask me).
>
>> You are right to be suspicious of G-Wan. Regardless of the merits of the
>> software itself, its author is known for his aggressive propaganda of
>> G-Wan, including attempts to cover up serious past security
>> vulnerabilities.
>
> Hm, yet I never heard about G-WAN at all until somebody brought it up in the NG.
>
>> Have a look here to get an understanding of how far this goes:
>>
>> http://www.wikivs.com/index.php?title=G-WAN_vs_Nginx&action=history
>>
>> More info:
>>
>> http://weblambdazero.blogspot.com/2011/09/human-factor.html
>
> This in fact it contains a bunch of accusations of it's own.
> It's not like I should have posted all this (everybody knows better then to trust anonymous blindly etc.) but just could not resist.

OTOH, it seems to me that a web server that relies on C for everything **is** very strongly subject to security issues. The code that generates pages must be absolutely bug free before being put in production, which is hard with C for anything that is not trivial.

On Sunday, 1 July 2012 at 08:04:48 UTC, SomeDude wrote:
>
> OTOH, it seems to me that a web server that relies on C for everything **is** very strongly subject to security issues. The code that generates pages must be absolutely bug free before being put in production, which is hard with C for anything that is not trivial.

And judging by the discussion below the blog post, the author (if we assume he is posting under "AnotherHumanBeing") seems to have a serious personality issue.

On 01-Jul-12 12:29, SomeDude wrote:
> On Sunday, 1 July 2012 at 08:04:48 UTC, SomeDude wrote:
>>
>> OTOH, it seems to me that a web server that relies on C for everything
>> **is** very strongly subject to security issues.

Yes, it's one things I don't like about it - apparently GWAN would crash the moment your C servlet segfaults. Ah, the pleasure of native scripts ;)

The code that
>> generates pages must be absolutely bug free before being put in
>> production, which is hard with C for anything that is not trivial.
>
Use D! :) Or any other language, I see a list of supported native languages in its docs.

The fact that most production libraries (that are portable) are written in C largely defeats the point of
"... must be absolutely bug free before being put in production, which is hard with C for anything that is not trivial. "

Also web server need NOT be absolutely bug free. It just shouldn't CRASH. So memory corruption is no go, logic errors and such are possible. Software always has bugs, there is no such thing as "bug-free" for anything not trivial. It's just they are not important or hard to trigger + "lack of feature" bugs.

BTW PHP is a hell of a bug (not counting bugs in scripts) yet it's out in the open serving most of web sites today.

> And judging by the discussion below the blog post, the author (if we
> assume he is posting under "AnotherHumanBeing") seems to have a serious
> personality issue.

I would refrain from _assuming_ who is who over the internet as I made terrible mistakes in the past :)
In any case what's obvious is that GWAN author is on knives with an awful lot of people, and of obvious reasons I see it being closed source. Kind of reminds me of "OMG! DMD not truly OpenSource!!!" posts around here.



-- 
Dmitry Olshansky

On Sunday, 1 July 2012 at 11:22:53 UTC, Dmitry Olshansky wrote:
> On 01-Jul-12 12:29, SomeDude wrote:
>> On Sunday, 1 July 2012 at 08:04:48 UTC, SomeDude wrote:
>>>
>>> OTOH, it seems to me that a web server that relies on C for everything
>>> **is** very strongly subject to security issues.
>
> Yes, it's one things I don't like about it - apparently GWAN would crash the moment your C servlet segfaults. Ah, the pleasure of native scripts ;)
>
> The code that
>>> generates pages must be absolutely bug free before being put in
>>> production, which is hard with C for anything that is not trivial.
>>
> Use D! :) Or any other language, I see a list of supported native languages in its docs.

What I meant was, the author of G-WAN boasts high performance because his servlets are in C. But making a dynamic website in C is very both unproductive and very risky, security wise, so very few companies would do that unless for delivering static pages. And if you use another language, then the performance drops and I suppose you get performance closer to nginx and lighthttpd (with D and C++, less than with some other languages).

> The fact that most production libraries (that are portable) are written in C largely defeats the point of
> "... must be absolutely bug free before being put in production, which is hard with C for anything that is not trivial. "
>
> Also web server need NOT be absolutely bug free. It just shouldn't CRASH. So memory corruption is no go, logic errors and such are possible. Software always has bugs, there is no such thing as "bug-free" for anything not trivial. It's just they are not important or hard to trigger + "lack of feature" bugs.
>

As you say, memory corruption is a no go, so I would probably never use C for a serious website.

> BTW PHP is a hell of a bug (not counting bugs in scripts) yet it's out in the open serving most of web sites today.

Yes but PHP doesn't suffer too many memory corruption bugs, so there is no risk of shell code injection.

On 01-Jul-12 19:54, SomeDude wrote:
>> Use D! :) Or any other language, I see a list of supported native
>> languages in its docs.
>
> What I meant was, the author of G-WAN boasts high performance because
> his servlets are in C. But making a dynamic website in C is very both
> unproductive and very risky, security wise, so very few companies would
> do that unless for delivering static pages.

No big wonder here. But you miss important point - it's fast not because it's written in C. Indeed Apache, Lightty, Nginix are all written in C.
It's just (at least seems to me) that author hates C++ and uses C as  a native language with least amount of baggage.

 And if you use another
> language, then the performance drops and I suppose you get performance
> closer to nginx and lighthttpd (with D and C++, less than with some
> other languages).
>
Why? The main point is architecture. In the same vain I've seen some Java servers that run faster then C ones. Architecture & careful low-overhead implementation is what crucial.
For one I totally expect vibe.d to kick some serious ass in the years to come.

>> The fact that most production libraries (that are portable) are
>> written in C largely defeats the point of
>> "... must be absolutely bug free before being put in production, which
>> is hard with C for anything that is not trivial. "
>>
>> Also web server need NOT be absolutely bug free. It just shouldn't
>> CRASH. So memory corruption is no go, logic errors and such are
>> possible. Software always has bugs, there is no such thing as
>> "bug-free" for anything not trivial. It's just they are not important
>> or hard to trigger + "lack of feature" bugs.
>>
>
> As you say, memory corruption is a no go, so I would probably never use
> C for a serious website.
>

Right that's why static files are served as files not as a servlet per page. Modules of say Apache will crash it just as easy (okay one of Apache worker processes).
If I were to use GWAN (I'll certainly give it a try some day) then I'd use things like template engine and maybe doing some risky stuff in 2nd 'mule' process. And no that != kill performance.

>> BTW PHP is a hell of a bug (not counting bugs in scripts) yet it's out
>> in the open serving most of web sites today.
>
> Yes but PHP doesn't suffer too many memory corruption bugs, so there is
> no risk of shell code injection.

Mm... the interpreter itself is bad enough. Like being not thread safe (is it now?). But the main problem though is bad practices that PHP spawned an masse. Last time I checked vulnerabilities database SQL injections and PHP were commonly found in the same statement/article.

-- 
Dmitry Olshansky