Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nginx 1.9.11 with Dynamic Modules

mailman.nginx.org

Post reply on HN
Print view View original

51–60 of 63 posts

Re: Nginx 1.9.11 with Dynamic Modules

#51

Post by snuxoll »

pilif wrote: post #6
stereo wrote: post #3

This is great news for the pagespeed people.

not just for them. This also helps a lot for all OS packagers because right now they have to ship multiple custom nginx packages. As a user you either don't get what you want or you get way too much. Plus, if there's a custom module you'd really like to have in your nginx you're practically forced into building your own because there's no way to get that module loaded into the distro nginx. Yes. There's some overhead…

> This also helps a lot for all OS packagers because right now they have to ship multiple custom nginx packages. As a user you either don't get what you want or you get way too much.

I guess it allows us to split the nginx-included modules into separate packages, but it does nothing to aid with packaging extra modules until nginx provides a stable ABI for modules to use.

Re: Nginx 1.9.11 with Dynamic Modules

#53

Post by vbtechguy »

jweir wrote: post #38
derFunk wrote: post #30

Earlier quoted context omitted.

Honest question: Why do you think it was non-trivial? What is/was complex?

Time of compilation is one issue. If you just wanted to add a module you would have to recompile everything. Likewise if you want to remove a module. Although one advantage of requiring compilation is the user is probably more likely to use the latest version.

you can reduce re-compilation time by using ccache compiler caching. i do this for my Centmin Mod LEMP stack auto installer and re-compile via ccache is up to 60-80% faster than without ccache https://ccache.samba.org/ :)

Re: Nginx 1.9.11 with Dynamic Modules

#54

Post by vbtechguy »

cbr wrote: post #26
toupeira wrote: post #24

Earlier quoted context omitted.

Compiling a module is still a lot more straight-forward than recompiling the whole of Nginx, which is probably the main obstacle to people using it (at least it is in my case).

Cool. We're working now to make this possible. (And, in fact, to work at all when compiling against 1.9.11, since the addition of dynamic modules broke us: https://github.com/pagespeed/ngx_pagespeed/issues/1110 )

Piotr is working his magic for ngx_pagespeed 1.10 https://github.com/pagespeed/ngx_pagespeed/issues/1114 just need a patch for 1.9 branch too

Re: Nginx 1.9.11 with Dynamic Modules

#55

Post by [deleted] »

cbr wrote: post #26
toupeira wrote: post #24

Earlier quoted context omitted.

Compiling a module is still a lot more straight-forward than recompiling the whole of Nginx, which is probably the main obstacle to people using it (at least it is in my case).

Cool. We're working now to make this possible. (And, in fact, to work at all when compiling against 1.9.11, since the addition of dynamic modules broke us: https://github.com/pagespeed/ngx_pagespeed/issues/1110 )

[deleted]

Re: Nginx 1.9.11 with Dynamic Modules

#56

Post by jrc7 »

snuxoll wrote: post #48
voltagex_ wrote: post #46

Earlier quoted context omitted.

This is off topic, but I think there should be more tutorials for developers along the lines of "how to make life easier for packagers". Sidenote: creating Debian packages is an intimidating task.

1. Don't use a million dependencies that aren't already included in the majority of distributions. As a packager, I have no desire to maintain 20 complicated libraries you decided to depend on just to include your application in the package collection. A couple is fine, and the flatter your dependency tree is the less painful it is for a package maintainer to deal with. If you must include a dependency then please ke…

1. As a developer, I couldn't care less about making your life easier at the expense of making mine more difficult.

3. I couldn't care less what you won't package. Especially so if it's due to prioritizing your own needs over everyone else's. Take it or leave it.

4. Distributions are already woefully inconsistent anyway. If you're going to package something, the entire burden is on you.

Distributions have had too much influence over upstream projects for way too long. Thank god people are finally starting to reject their diva-like, our-way-or-the-highway attitudes. I have been a package maintainer for both Fedora and Debian, and frankly, for things outside of the core OS/libs/compilers/tools, using deb/rpm packaging is very, very overrated. Likewise for dynamic linking.

Re: Nginx 1.9.11 with Dynamic Modules

#57

Post by ArmTank »

frik wrote: post #49
akurtzhs wrote: post #40

Earlier quoted context omitted.

What problems are you having using stub_status? I'm using the nginx mainline PPA and didn't have a problem enabling it.

This module is not built by default, it should be enabled with the --with-http_stub_status_module configuration parameter I had to compile Nginx myself, because that module was absent. As you can read also on various community pages, boards, etc. Nginx is the only server software that I have to compile myself, just to get a basic status feature. It's a way to upsale people to their NginxPlus which offer a lot more st…

http://nginx.org/en/linux_packages.html#arguments

  Configure arguments common for nginx binaries
  from pre-built packages for stable version: 
  ...
  --with-http_stub_status_module
  ...

Re: Nginx 1.9.11 with Dynamic Modules

#58

Post by snuxoll »

jrc7 wrote: post #56
snuxoll wrote: post #48

Earlier quoted context omitted.

1. Don't use a million dependencies that aren't already included in the majority of distributions. As a packager, I have no desire to maintain 20 complicated libraries you decided to depend on just to include your application in the package collection. A couple is fine, and the flatter your dependency tree is the less painful it is for a package maintainer to deal with. If you must include a dependency then please ke…

1. As a developer, I couldn't care less about making your life easier at the expense of making mine more difficult. 3. I couldn't care less what you won't package. Especially so if it's due to prioritizing your own needs over everyone else's. Take it or leave it. 4. Distributions are already woefully inconsistent anyway. If you're going to package something, the entire burden is on you. Distributions have had too muc…

> 1. As a developer, I couldn't care less about making your life easier at the expense of making mine more difficult.

Great, and nobody said you had to. If someone likes your application enough and they want to get it packaged they will - personally, however, ease of packaging is something that makes or breaks whether I "like" something - which is why as much as I love Mumble I'm not putting any effort in to revive its package in Fedora, because ICE is a huge pain in the butt to build and I just don't want to waste time on it.

> 3. I couldn't care less what you won't package. Especially so if it's due to prioritizing your own needs over everyone else's. Take it or leave it.

Outside of commercial distributions this is literally how everything works. I package things that are useful to me that I hope would be useful to other people, but I don't know of many package maintainers that spend time on software they personally have no use for.

> Distributions have had too much influence over upstream projects for way too long. Thank god people are finally starting to reject their diva-like, our-way-or-the-highway attitudes.

If you don't want distributions to have so much influence over packaging your software then do it yourself, nothing makes me happier than seeing .spec files or debian/ folders inside a repository of some application I'm looking at - 99% of the work is already done outside of maybe cleaning the scripts and metadata up to meet packaging standards.

> and frankly, for things outside of the core OS/libs/compilers/tools, using deb/rpm packaging is very, very overrated.

I too at one point believed this, but then I remembered how crappy package management on Windows is as a result of this philosophy. They even HAVE a package manager (MSI/Windows Installer) that nobody uses properly! And you know what, good luck hoping all your applications have kept every dependency and every transitive dependency they bundled in up to date - when you get your package included in a distribution that's done for you by the package maintainer that is supporting your package.

> Likewise for dynamic linking.

Strongly disagree. I hope you have fun downloading update bits for every application that statically links against openssl next time some stupid bug like heartbleed comes along. I still think Google made the wrong call with Go, same goes with Mozilla and Rust.

Re: Nginx 1.9.11 with Dynamic Modules

#59

Post by kibwen »

snuxoll wrote: post #58
jrc7 wrote: post #56

Earlier quoted context omitted.

1. As a developer, I couldn't care less about making your life easier at the expense of making mine more difficult. 3. I couldn't care less what you won't package. Especially so if it's due to prioritizing your own needs over everyone else's. Take it or leave it. 4. Distributions are already woefully inconsistent anyway. If you're going to package something, the entire burden is on you. Distributions have had too muc…

> 1. As a developer, I couldn't care less about making your life easier at the expense of making mine more difficult. Great, and nobody said you had to. If someone likes your application enough and they want to get it packaged they will - personally, however, ease of packaging is something that makes or breaks whether I "like" something - which is why as much as I love Mumble I'm not putting any effort in to revive i…

  > same goes with Mozilla and Rust.
Dynamic linking in Rust is as easy as passing in a single compiler flag, which is what I expect distro package managers will do when building packages written in Rust.

Re: Nginx 1.9.11 with Dynamic Modules

#60

Post by mixmastamyk »

uggedal wrote: post #39
mixmastamyk wrote: post #16

load webserver.nlm (a reference for the old-timers here) Seems an odd feature for 1.9.11, why not wait for 2.0?

The 1.9 series is unstable (mainline) while 1.8 is stable. Classic odd/even unstable/stable versioning.

This is the answer, I had forgotten about this strategy.
Post reply on HN