[HN Gopher] Do svidaniya, Igor, and thank you for Nginx
___________________________________________________________________
Do svidaniya, Igor, and thank you for Nginx
Author : nrvn
Score : 188 points
Date : 2022-01-18 21:10 UTC (1 hours ago)
(HTM) web link (www.nginx.com)
(TXT) w3m dump (www.nginx.com)
| granshaw wrote:
| I remember the days circa 2009 when the Nginx docs pages still
| had lots of Soviet-style graphics... those were the days :)
| pupppet wrote:
| What an impact, great job Igor!
| schoolornot wrote:
| It still surprises me that NGINX beat out Apache so quickly even
| though Apache had way more modules and was/is entirely free vs.
| NGINX which is more or less "open core" with some nice features
| requiring commercial licensing.
| qbasic_forever wrote:
| The web changed. We moved away from static HTML pages and CGI
| scripts to monolithic application servers in java, ruby,
| python, etc. Apache excelled with these static content sites
| and simple auth scenarios (remember .htaccess files?) but
| became painfully complex proxying application servers. Nginx
| was doing exactly what was needed at exactly the time it was
| needed.
| f311a wrote:
| Which modules do you miss in nginx that are free in Apache?
| masklinn wrote:
| On the other hand, the unreadable weird-ass pseudo-XML
| configuration files of Apache made anyone touching them wish
| for something better.
|
| I also expect ngx_lua did _a lot_ for adoption, the fact that
| you could always "shell out" to lua if you needed was a huge
| boon even just for peace of mind.
| nkozyra wrote:
| > On the other hand, the unreadable weird-ass pseudo-XML
| configuration files
|
| If I have one gripe about NGINX it's that its configuration
| is a still-half-baked DSL that has quirks you wouldn't expect
| and when they error you don't get great feedback.
|
| Examples: You can have an if clause, but no else attached.
| You can't have an if clause with multiple conditions.
| Finally, "if [might be] evil." 1
|
| You end up writing a bunch of partitioned control flow
| statements and you're never really sure at what level of
| config hierarchy they would best be applied.
|
| I love the product but Apache's XML versus NGINX's semi-
| declarative, hierarchical blocks aren't night and day better.
|
| 1 https://www.nginx.com/resources/wiki/start/topics/depth/ifi
| s...
| yesbabyyes wrote:
| To me, it coincided with async (long polling/comet/SSE), more
| live, web applications. Apache had a horrible story around
| this, with one thread per connection (I believe Apache 2 may
| have had an optional execution model, which was also
| uncomfortable for some reason).
|
| I used lighttpd for this, mentioned in another thread, rather
| than nginx, which was a similar breath of fresh air coming from
| Apache -- not only for the event loop model built around epoll
| and friends, but also the configuration and general deployment.
| SkyPuncher wrote:
| For me, the simplicity of Nginx is what beats it out over
| Apache.
|
| I've always felt like Nginx "just works" by default and
| creating configurations is relatively easy.
| lstodd wrote:
| Back when the Apache was beaten there was no commercial
| licensing in Nginx.
|
| Also the Apache that was beaten was Apache 1, which was fork-
| only, and that was the whole reason Nginx was written in the
| first place.
|
| Then Apache did Apache2 with mpm modules and badly missed the
| mark. After that Apache was doomed. No async support == dead.
| It was that simple.
| jacquesm wrote:
| Convenience is often worth a lot more than the ultimate in
| flexibility.
|
| This is why email is now more or less the domain of a couple of
| very large companies.
| nkozyra wrote:
| I really take for granted how well Nginx works across a number of
| web backend functions.
|
| Some of the container/orchestration world has tried to supplant
| the need for it as a reverse proxy, but you get so many goodies
| out of the box just by sticking this in front of your app, and
| for very little overhead.
|
| I remember the pre-Nginx days and all of the struggles people
| routinely ran into with options like Apache or other reverse
| proxy tools.
| stormbrew wrote:
| I mean there was lighttpd before nginx and they have/had pretty
| similar structures, weights, etc.
|
| I feel like I knew at one point why it got so thoroughly
| supplanted by nginx but I don't remember now why that happened.
| simonw wrote:
| The performance engineering in NGINX back then was really
| quite something.
|
| This classic 2007 tutorial starts by pointing out that NGINX
| parses the HTTP verb by looking at the second letter first,
| so that if it's O it knows to check for POST or COPY!
|
| https://web.archive.org/web/20070505051653/http://www.riceon.
| ..
| danachow wrote:
| Does it really look at second letter first or is that
| snippet taken out of context (it isn't implied that it does
| in that email, just that it doesn't use a library function)
| ? Since most requests are GET it still makes sense to
| handle that case first. Though after trying to common cases
| looking at the second letter for the P subcases may save
| some branching.
| MaxBarraclough wrote:
| Doing Boyer and Moore proud.
|
| I think that if you want to support all verbs, you face at
| least 3 'ambiguities' whether you first check the first,
| second, or third character of the string. (It must be at
| most the third, as the shortest verbs are 3 characters
| long.)
|
| First checking the first character is ambiguous between
| _POST_ , _PUT_ and _PATCH_. First checking the second
| character is ambiguous between _HEAD_ , _DELETE_ , and
| _GET_. First checking the third character is ambiguous
| between _GET_ , _PUT_ , _OPTIONS_ , and _PATCH_. [0]
|
| _edit_ As danachow points out, the verbs are not all used
| with the same frequency. If real-world performance is the
| goal we 'd presumably want to optimise for the _GET_ case,
| which presumably means first checking the first character,
| as the 'G' is unique to _GET_.
|
| [0] https://developer.mozilla.org/en-
| US/docs/Web/HTTP/Methods
| stormbrew wrote:
| Seems likely an optimal algorithm could probably get
| there just looking sequentially at the first three
| letters in order. Would be an interesting code-golf.
| univalent wrote:
| Oh my gosh, I thought he passed away.
| eliseumds wrote:
| People need to stop with this Cloudflare captcha madness. I
| literally accessed nginx.com a few hours ago and now it hit me
| with a captcha again.
| Suchos wrote:
| Are you using Safari by any chance? I used to get a lot of
| these on Safari, but issue is almost gone on Firefox. I think
| it's connected to how Safari handles cookies.
| [deleted]
| shadowgovt wrote:
| Cloudflare uses a heuristic trust model where it pulls multiple
| trust signals from the client. It can use several things
| (including stable IP address, cookies, and I think even a bit
| of JavaScript grabbing a nonce from local storage).
|
| If you run with a lot of "identity fuzzers" (browsing through
| Tor, JavaScript off, cookies banned), Cloudflare can't build
| its trust heuristics and needs to challenge-response more
| often. I suspect there's overlap between HN readers and use of
| those sorts of tools, so I think there is a disproportionate
| number of people around here who run into this issue (whereas
| most "regular" folk almost never see a Cloudflare challenge /
| response).
| mastazi wrote:
| > Cloudflare uses a heuristic trust model where it pulls
| multiple trust signals from the client.
|
| The wording "heuristic trust model [...] trust signals from
| the client", would not be out of place in the context of a
| sigint discussion.
| rzzzt wrote:
| I always encounter a "random" stop-and-solve-me-a-visual-
| puzzle when visiting an Australian forum related to SOHO
| networking equipment. According to the description on the
| challenge page, "completing the CAPTCHA proves you are a
| human and gives you temporary access to the web property".
| Thank you, Cf, I guess?
|
| (To be fair, consecutive requests don't get this treatment,
| just the one in which I jump there from eg. a search result.)
| petre wrote:
| They are breaking the web, plain and simple. Google with AMP,
| Cloudfare with their idiotic capchas.
| shadowgovt wrote:
| No server is obligated to vend my client data.
|
| More importantly: no server is obligated to vend data until
| it falls over and dies, depriving _all_ users access to
| that data if it isn 't mirrored.
|
| I think Cloudflare has honestly done an admirable job of
| coming up with a novel solution to the problem of
| loadbalancing and traffic-shedding in a world with a small-
| but-persistent percentage of hostile actors.
| shadowgovt wrote:
| Impressive. I thought the only way you were allowed to quit
| working on an open source project was to commit a new version
| where you delete everything and introduce a chunk of code to put
| clients into an infinite loop. I'm impressed Igor was able to
| find an alternative. /s
|
| (More seriously though, his work is impressive and I hope his
| next adventure is at least as fulfilling).
| er4hn wrote:
| Igor and the rest of the Nginx team achieved commercial
| payments by offering premium modules. Later on they were
| acquired by F5 networks. He achieved the goal.
| hardwaresofton wrote:
| One could only hope to build software as great as NGINX, keep it
| up for 20 years and receive a send off like this.
|
| Bravo
| devy wrote:
| It took a good 5 minutes read of the entire blog post to
| understand that "Do Svidaniya" is actually "Do Svidaniia"
| (Russian), meaning "Goodbye".
| ianai wrote:
| I thought maybe it was somebody's name and just a really
| horribly formed sentence. Because, ya know...
| jacquesm wrote:
| Listen to more Zemfira...
| [deleted]
| [deleted]
| mxuribe wrote:
| Thank you for all the you have done Igor!
| zzt123 wrote:
| Thank you Igor for Nginx. Love using it!
| mobilio wrote:
| To non-russian speaking users: "Do Svidaniya" means "Goodbye".
| smarx007 wrote:
| To add a bit more, "svidaniye" means a date, and "Do svidaniya"
| literally means "till [our next] date". In English, "see you"
| or "see you later" translates closest to the original phrase in
| Russian.
| Croftengea wrote:
| "Do svidaniya" sounds more formal than "See you" though.
| smarx007 wrote:
| That is true, thank you for pointing it out. My personal
| preference is "vsego Vam dobrogo", which is even more
| respectful (it translates roughly as "All the kind (best)
| to You").
| pvg wrote:
| I think in general, it's probably best to avoid this kind
| of etymological explanation of the 'actual meaning' of
| some word or expression because they tend to obscure the
| usage and, well, actual actual meaning. Saying 'goodbye'
| in English doesn't really mean saying 'God be with you'
| to someone, even though that's what it's originally a
| contraction of. They're fine as etymology, of course!
| hprotagonist wrote:
| >Saying 'goodbye' in English doesn't really mean saying
| 'God be with you' to someone
|
| except, of course, when it does.
|
| I regularly re-pronounce holiday as holy-day internally,
| and the same with welcome and well-come; i am, of course,
| a weirdo.
| xvedejas wrote:
| As a Russian learner, it seems a bit wrong not to
| transliterate that as "vsevo Vam drobovo" even though I
| understand that's not how it's spelled originally. For
| whatever reason, that's what my brain is expecting.
| smarx007 wrote:
| I actually wanted to write "vsevo Vam dobrava" (o not
| under stress often becomes a) but changed it to an
| grammatical transliteration for some reason.
| marginalia_nu wrote:
| "Farewell"?
| smarx007 wrote:
| Not exactly. You bid farewell with "proschayte"
| (literally begging for forgiveness) or "vsevo dobrava"
| (wishing all the kind/best), but "do svidaniya" has a
| hint of looking forward to meet your counterpart again.
| loeg wrote:
| "Until we meet again"
| rzzzt wrote:
| Auf Wiedersehen!
| smarx007 wrote:
| Genau! Actually, this perfect duality also extends to
| other phrases, like "priyatnava appetita", just like
| Guten Appetit! At the same time, in Ukrainian you'd say
| "smachnogo", similar to Swedish "smaklig maltid" (lecker
| Mahlzeit), as "smak" means taste in both languages.
| egman_ekki wrote:
| Doesn't it literally mean "Until we see each other [again]",
| which is even closer to "See you"?
| smarx007 wrote:
| It does mean exactly that, though not literally (there are
| only two words in the phrase literally).
| [deleted]
| app4soft wrote:
| Here are relevant Russian discussions on OpenNET[0] & LOR[1].
|
| N.B. From _Nginx_ company history on Wikipedia:
|
| > _On 12 December 2019, it was reported that the Moscow offices
| of Nginx Inc. had been raided by police, and that Sysoev and
| Konovalov had been detained. The raid was conducted under a
| search warrant connected to a copyright claim over Nginx by
| Rambler--which asserts that it owns all rights to the code
| because it was written while Sysoev was an employee of the
| company. On 16 December 2019, Russian state lender Sberbank,
| which owns 46.5 percent of Rambler, called an extraordinary
| meeting of Rambler 's board of directors asking Rambler's
| management team to request Russian law enforcement agencies cease
| pursuit of the criminal case, and begin talks with Nginx and with
| F5._[2]
|
| [0] https://www.opennet.ru/opennews/art.shtml?num=56535
|
| [1] https://www.linux.org.ru/news/opensource/16745652
|
| [2] https://en.wikipedia.org/wiki/Nginx#History
| avrionov wrote:
| Was the case resolved? Wikipedia doesn't provide any further
| information?
| smarx007 wrote:
| I think Wikipedia characterization is also incorrect. Igor
| seems to have a permission directly from the CTO to open-
| source the code, but 10 years later the company claimed that
| the CTO was not in a position to do so.
| chx wrote:
| Yes, Wikipedia -- in broad strokes -- just sucks, check what
| happened to the Scottish Wikipedia (but there are any number
| of issues in the English one as well, the "no credentials"
| policy made sure scientists shun it because they want to
| argue with neckbeards with an agenda).
|
| Anyways, https://tadviser.com/index.php/Company:Nginx
| everything is dropped in Russia, there's a lawsuit in the US
| but at first the court dismissed the whole thing in 2021, I
| expect that one go exactly nowhere.
| pmontra wrote:
| You can find a summary at
| https://tadviser.com/index.php/Company:Nginx
|
| TL;DR: the Russian investigators closed the case of Rambler
| Group against Nginx/T5 in 2020 "for the absence of a crime
| event". Another company co-owned by the same owner of Rambler
| Group started a case in the USA but it was dismissed by a
| court in California in 2021.
| [deleted]
| nimbius wrote:
| unrelated but ive always thought the F5 acquisition of NGINX made
| little sense. I think F5 saw the writing on the wall a little
| late, panicked, and bought the first competitor they could come
| up with that showed up in a Gartner quadrant.
|
| so much of the NGINX product that aligns with F5 as a competitive
| element is essentially already implemented and free by people who
| are already completely competent in load balancing. unless
| companies seek to reduce risk by bolting on a support
| contract...why F5 at all?
|
| can someone from the biz side of the HN house chime in perhaps?
| oneplane wrote:
| I mostly see it in businesses that aren't very competent and/or
| have a support/licensing partner that presents them a tunnel
| vision they cannot deviate from. F5 specifically is usually
| also just 'what they always had', or part of a bundle.
| nick__m wrote:
| iRule are the things that makes the F5 appliance special, it
| enables you to run TCL on a variety of events (ex:
| HTTP_REQUEST, CLIENT_CONNECTED...). Some typical uses are
| requests and responses modification, logging, bug fixes on
| closed source web applications... I also the F5 device support
| various permissions levels to enable delegation/separation of
| administrative privileges.
| ZoomZoomZoom wrote:
| Wow, you usually don't start a headline with "do svidaniya",
| unless it's for an obituary.
|
| Glad to see everything's fine.
| rzzzt wrote:
| My heart also skips a beat if I see a news article starting
| with "<First> <Last>, <occupation>".
| [deleted]
___________________________________________________________________
(page generated 2022-01-18 23:00 UTC)