G-WAN - Web Application Server
gwan.ch
gwan.ch
WTF? I mean, in what universe would I trust this sort of handwaving? Lumping people who might want to actually, y'know, audit the software they're running in with "oh my god they wants to steals my codes!"...I think I'll pass and encourage those I know to do likewise. (Plus, as cdcarter notes elsewhere in this thread, his reasoning for no OS X binary is incoherent at best, and reading posts by the author makes me wonder exactly what chain of jerkstores he's supplying with his attitude.)
> The next time someone feels the need to publicly call G-WAN's (1-page) license "weird" or "insane", look at what they sell and who they get their revenues from. Unlike for G-WAN, what they offer is not free for all.
They have redefined the word 'free' into a fine mist if they expect you to believe Apache and nginx are not free. They're doing something I've seen done before; oddly, it was mainly being done by Usenet trolls.
Every time I read something off that webpage my mental voice uses my Japanese "Engrish" accent to read it. So I can't say that I was really surprised when I saw that. (I'm actually getting the vibe that the lead developer may have lost a few of his marbles.)
At the same time it totally took a shotgun to the guys credibility when he implied that projects like nginx aren't free but G-WAN is.
Usually people map onmousedown,click,oncontextmenu, etc. events or some permutation there of to return false and have an alert that say's something to the effect of "no copying!"
You can easily defeat those by mapping whichever function to null on your javascript console. ie:
document.oncontextmenu = null
The Gwan guy's solution threw me off a bit because I was looking for another javascript version to no avail.In an interesting twist they've actually used css. That is every vendor permutation of.
user-select: none;
To disable that use your favorite developer tools and remove those styles from whichever element you want to copy..In GWAN's case (using Firefox) the rule was:
p, h1, h2, h3, h4, ul, ol, legend, label { -moz-user-select: -moz-none; }
I'm getting LoseThos vibes here a bit.
Copyright law gives users more rights than users or developers probably realise. Personally, I am happy to release my software with source code under either a simple copyright notice, or in the public domain with my moral rights asserted.
I suppose the HN crowd that legitimately wants to read code, but the majority of the people are going to go to the trouble are going to be programmers who are being whipped mercilessly to build some 3rd rate web app for their corporate masters, or competitors who want to improve their own technology.
BTW: Can you link the license page? I am looking for it, but can't find anything.
(Mind you: I do think the author is somewhat insane and sounds like almost every bitter 1980s programmer I ever met - but I'd like to see the insane conditions he imposes)
I don't use IIS either, and for similar reasons. I'm less worried about it on a desktop (and will run Windows or OS X without complaint) because they're not running things for which I have to care about performance or uptime. But for a service, it's non-negotiable.
His "product" is simply nowhere near valuable enough to risk this level of insanity and obfuscation.
I cannot comment on how much fast it is because it's been years since I ran benchmarks against it. Even supposing the claims are true, currently it's very limited in what languages it supports. It's great at static content, but dynamic content must be written in C or use a C library. In other words, PHP, Python, and Ruby support are pretty much non-existent (though someone has tried to get PHP FastCGI to work with it).
The author is also fairly arrogant. Earlier versions of the website claimed his code was "perfect" and that he wrote it because no else seemed competent enough to do it right (I'm trying to find the quote).
Regarding PHP: > And without something like G-WAN you can forget about PHP in the years to come because it will not survive the parallelism's requirements.
That is no longer accurate. G-WAN now supports C, Java, C++, D, and Objective C out of the box. [1] I am the someone who is implementing FastCGI support.
Second reaction: am I actually supposed to take seriously something that looks like that Java sample? 'Cause, er, I know a teeeeeensy bit about Java, and my first reaction was "what kind of moron would write Java like that?". Java isn't C, and this guy's bizarre worship of "programming to the metal" (it's a web architecture for god's sake!) makes no sense there.
It does not look like it's running in a normal JRE, which makes me really skeptical of the sibling post claiming that "you can write Java however you want". (If it was running in a normal JRE, a ton of the stuff in loan.java makes little sense...)
I'm not exactly sure how his claims of instant refreshing "scripts" works if it's a conventional JDK, though. I mean, that's just not possible, even with hot reloading (as Play Framework developers have learned to their disappointment).
On the other hand, I have written a few web applications in C. It's not that bad! :) The nice thing about it is that if you link statically, write CGI programs, and ignore memory management (or, rather, malloc all you care to and delegate garbage collection to the OS when your process goes away), you can get something that runs quickly with minimal hassle on a small device. I don't recommend it unless you have some bizarre constraints, but it's really not that bad! That approach doesn't seem possible with this server, sadly.
At that point the amount I trust 99.9% of C and C++ programmers to not screw the pooch (between dealing with HTTP requests, database interaction, string templating...) trends very close to zero. What you describe might be workable in the small, but at that point you might as well fling up Apache and mod_php. It'll probably be faster.
I think, though, that the database interacting, templating, etc., are things that you will very nearly always do in PHP because they're there. File-backed storage (if any storage is even needed) is more than adequate for most cases where one might write a CGI program in C. The last time I had occasion to write something from scratch and target CGI, I was generating graphs. No templating, no database, very fast.
The major pain of templating lies in C's string handling, though, and if you aren't worrying about freeing memory, there's not much pain. As far as HTTP goes, if the protocol was designed to be parsed in C, it's not often difficult to parse in C. But for all of those things, there's a library.
I can't comment specifically about whether or not mod_php would be faster (since I used PHP only briefly and several years ago) but I suspect very strongly that the overhead of firing up a small, statically linked C program beats it.
As I said previously, I don't think it's usually a good idea, but it's a more than viable tool and nice to keep in the box.
The author in a forum post did say that he doesn't think that FCGI is the right way to go and suggested asking Zend to build a C library for GWAN that could run PHP code [1]. I find that unlikely unless GWAN really starts getting a large following.
[1] http://forum.gwan.com/index.php?p=/discussion/comment/3801/#...
See [1] for reasons why PHP+FastCGI is a poor choice in 2012.
JavaScript, Lua, and Python can be linked directly with the server for performance you would not get via separate processes.
I had more difficulty with Go, which you can read about on the forum.[1]
They all work, but are just proofs of concept at the moment. G-WAN makes it easy to link with any C library, so it is not hard to use languages that expose a C API such as those listed. It is just a matter of writing a more complete handler.
[1]http://forum.gwan.com/index.php?p=/discussion/463/writing-g-...
I was intrigued by this and had a look. One level of the hierarchy requires directories either named with a starting # or $. !!! Possibly two of the worst leading characters to use if there's ever a chance one of these file names is going to hit a shell script. Or the command line. And since the point seems to be you can adjust the config by pushing things around with mv, seems like that's going to happen a lot.
Rule number one when putting your metadata in a filename is to not use shell metacharacters.
At my last company, we paid for a Zeus ZXTM license (which was an excellent product and very expensive for our little startup), and they didn't approach the level of arrogance here. The varnish guy is kind of opinionated, but he's got the chops to back it up, and you can, y'know, look at the source.
An obvious benefit of open source is also that if I take a large risk of running my business on your oddball web server and you get hit by a bus, I'm pretty much hosed. I'd rather buy 4 additional servers and run nginx than take that risk. Or, y'know, use a CDN.
Whatever, if the developers really are THAT much more skilled and their product is so far and away better than every other solution out there, then they should really hire someone who knows how to do marketing and PR properly, because they're not doing themselves any favors.
All of that aside, the motivation was that by using a product, instead of rolling our own solution, would be more maintainable, and we'd have a support contract. Compared with the mod_rewrite mess we had, ZXTM was a huge improvement. Plus we got stats, graphs, IP failover that worked flawlessly, active/active configuration sync, and a webui that made it so people who weren't intimately familiar with the config syntax of a variety of disparate services could perform fairly complex tasks (like A-B builds).
I mean, we also paid for Cisco ASA 5550s as a firewall/VPN solution for many of the same reasons. It all came down to what we wanted to spend our time engineering and what we could get management to spend money on. :)
You can still find the author accusing Microsoft of a Jihad against them on archive.org [1] or on their forums [2]
Their stance on open source rubs me the wrong way too... http://gwan.ch/faq#license
[1] http://web.archive.org/web/20101023050912/http://gwan.ch/en_...
[2] http://forum.gwan.com/index.php?p=/discussion/comment/3165/#...
> 199,999 [Swiss francs]: Use G-WAN under the brand of your choice (custom "Server: x" HTTP header).
This isn't the most insane upsell I've heard of, but it's close.
First of all, it is mostly one guy, and he seems exceptionally bright, and a bit freaking insane (Tesla was crazy but still smart, so it can work). I exchanged a few emails with him that combined with lack of access to the source drove me away from the project.
That said, every single claim he made I found to be either valid or an undersell on the actual performance (it did even better than he claimed in my tests). I was rather blown away by the performance, but the risk profile on it just made it unacceptable. Code C-Script (it supports more now, I am aware, but at that point it was C), no source, [possibly] nutjob one man show, no ability to easily hire people to work on it (which to be fair is entirely chicken and egg).
But, it is still a project I watch with mild interest... and I do encourage people to try it (great comment on this thread how to run it as a user http://news.ycombinator.com/item?id=4110247) and try it out, if nothing else it is extremely opinionated software, and it really is borderline insanely fast.
Sounds like there's some real bright ones on this development team.
For dynamic content multi-process servers are still just fine because your code/DB requests are going to block for long periods, which is far easier than writing non-blocking code. Putting an event-based server in front of a multi-process server for dynamic stuff gets you the best of both worlds.
Something like G-WAN might have a niche for the few people that need to write some piece of their service in C for performance reasons. But, you can pretty easily do that as an nginx module as well, and it's simply not necessary except in very rare cases.
It seems neat, but I don't think it's of much use to most people.
sudo ./gwan
Now go to localhost:8080 to try the demos!
But wait, I don't need root to open port 8080. So why sudo? Maybe some weird install procedure runs.... No thanks.It's also claimed that this is the only optimisation required or available for speed.
Remove sudo and the examples still work.
That this is termed "an optimization" terrifies the shit out of me. Even moreso than the whole "hey, run it as root, broseph!" part.
I am unsure why you are carrying this dude's water, but nothing I have seen makes anything related to this project seem either sane or production-safe. There is crazy in these hills, my friend. Undiluted.
What word do you suggest I use to describe configuring a program to have access to more sockets?
> Even moreso than the whole "hey, run it as root, broseph!" part.
In daemon mode, G-WAN drops privileges to the user and group of your choosing.
sudo chpst -u gwan:gwan -o 100000 ./gwan
This uses the chpst utility from runit to do pretty much exactly what you described: set uid/gid, change the file descriptor limit, drop privileges, and execute ./gwan. For similar reasons, it feels crazy that people still manually write code to handle daemonization and pidfile handling, when there are easy tools that will handle that for you, and generally do a really good job of it. Isn't that the Unix Way?Like I said, "terrifying" is a good one. Reserving blocks of sockets in that sort of size is notably odd and from a performance standpoint it's pretty hard to argue that it's necessary.
> In daemon mode, G-WAN drops privileges to the user and group of your choosing.
I would assume that it would setuid down to something sane, sure, but that's not the WTF part: it's that I'm supposed to run closed-source code by some guy as root on my server machines.
"And this test is merely a single-thread test. Add concurrency and SQLite as well as Tokyo Cabinet die in pain because a single write blocks other read/write threads.
Not in G-WAN's case. It is never ever blocking nor delaying any processing.
How solid is it? G-WAN relies on it and has been tested with low and high concurrencies."
I don't want all my comments here to be slamming this project, I just do not understand this maintainers mind.
I've compared it and can back that up and I think that TC learned a lot with Kyoto Cabinet as you can read on their page. Did you even compare SQLite and TC vs G-WAN KV yourself before posting this?
How come I am only hearing about it now?
Nobody wants to 'steal code', its that code for a WebServer isn't something worth stealing.
As for being amazingly fast? I can write an AMAZINGLY fast server capable of serving up 'Hello, World!' at speeds that can blow everything else outta the water; of course this is of no use to anyone anywhere.
G-WAN is not merely a "hello world" server. See [2] for the API features and [3] for more details.
I have tested the claims and find them to be legitimate.
If you have a more specific question, I may be able to provide more details.
* A small, yet useful set of core APIs (http://gwan.ch/api)
* Applications are recompiled on the fly when a change is made
* A "no compromises" attitude to performance and software design
* It supports legacy applications written in CGI-style without the cost of CGI
See this article for an interview with the author of the project[1]Perhaps these forum threads will help.[1][2]
[1]http://forum.gwan.com/index.php?p=/discussion/393/how-to-dis...
[2]http://forum.gwan.com/index.php?p=/discussion/comment/5812/
> You have to change the PATH variable if you want to call programs without specifying their location.
If it isn't, then they have totally failed at marketing and should try to fix that.
LOL
I mean other than the licensing and the attitude of its programmer.
* G-WAN is not open-source, so people (justifiably) resist trying it.
* It lacks software that takes advantage of the platform.
* G-WAN gets limited coverage on news sites. (it's banned from Wikipedia for example)
* People react negatively to the extraordinary claims made by its author without verifying them with the provided benchmark toolAnd it's not banned from Wikipedia, it's just deemed not relevant. But that can't be all, can it?
As for the second, I agree that the source of those "units sold" should be cited.
They claim their algorithm is impossible to solve using robots... When it is obvious that it isn't impossible...
The purpose of the example is to give you a basis on which you could implement an effective CAPTCHA.
The claim of "difficult or even completely impossible for robots" applies to CAPTCHAs using the above techniques, which are not used in the example.
.. right.
The reply:
Google search results for:
"a-wan web server": About 8,030,000 results (0.29 seconds)
"b-wan web server": About 5,600,000 results (0.21 seconds)
"c-wan web server": About 4,010,000 results (0.28 seconds)
"d-wan web server": About 3,410,000 results (0.29 seconds)
"e-wan web server": About 2,770,000 results (0.25 seconds)
"f-wan web server": About 2,430,000 results (0.27 seconds)In the latter case you have proven software that is easy to set-up and scale. If need more, then :
- add more nginx/more gunicorns - add haproxy - add DNS balancing
So, what's the point?
See page 2 of http://gwan.ch/archives/g-wan_case.pdf.
I don't have time and 15 years of programming under my belt.
I found out about this after searching for nginx/apache alternaitives, and it seems to domeinate everything except the ram usage of nginx.
[1]http://nbonvin.wordpress.com/2011/03/24/serving-small-static...
[1]http://nbonvin.wordpress.com/2011/03/24/serving-small-static...