I concur on using an adblocker to block modals, cookie notices, dickbars, related articles, author profile pictures, etc. In fact, I never dismiss modals because doing so may imply consent to tracking cookies (you never know these days…). I just block them with a quick cosmetic selector-based filter.
Unless it's a personal site/blog I typically open a site to find information I came for, and close it as soon as that task is done. Anything that makes this take longer than it needs to gets blocked. Sites should strive to stay open for as few seconds/minutes as possible while still giving me the requested information.
Regarding text/image-focused sites that require JS: I generally find sites made by people who haven't figured out how to send text over HTTPS to have low-quality content befitting of their low-quality stacks. I'm all the better for using my adblocker to block them from my search results page forever; it saves me time in the long run.
First off, some of your comments have referred to ad-blocking being wrong due to conflict with existing business models.
Businesses are not entitled to the success of their business models. If a business model fails due to consumer behavior, the business was in the wrong for expecting different behavior.
> I would be fine with ad blockers that only blocked ads, as long as publishers could chose to refuse service to users running ad blockers or ask them to turn their ad blocker off.
Distracting content (most ads), color schemes with bad contrast, bright images on dark pages, etc. are accessibility hazards (particularly cognitive accessibility hazards). Restricting the use of page-alteration software (e.g. color and font alteration, disabling images, and blocking frames) is therefore a discriminatory practice.
In a sibling subthread:
> The part of your analogy where you say people who want burgers don't have any other choice seems not to fit: you can eat other foods which don't have this requirement, just like there are lots of places on the internet where you can exchange money for ad-free content.
The libertarian perspective is a two-way street. Nobody is forcing a person to publish content on the Web. If the "comply with the user's wishes" model of the Web is problematic to a content creator, they don't need to participate in the Web.
I generally recommend Caddy over Nginx, but Nginx does still have certain advantages:
- Nginx supports OpenSSL commands that enable features like TLS record padding.
- Performance: better latency and scalability to more connections. Not everyone uses a CDN for static/cached content
- Kernel-accelerated TLS offload on Linux and FreeBSD
- Many existing modules provide unique functionality. The many modules for live video streaming and image processing are good examples.
- An ecosystem of patches with features like HPACK static dictionaries, dynamic TLS record sizing, etce
> …has terrible language integration.
Generally, "language integration" isn't really a use-case for vanilla Nginx; it's a use-case for Nginx Unit, an Nginx language-specific module, or OpenResty. I personally prefer the reverse-proxy route since it lets me use whatever language I want regardless of server support: Go, Rust, Python, C, etc.
If none of these are that important then I absolutely would not recommend Nginx; Caddy would be the better tool.
> People aren't writing internet scale software in lua for a reason.
I'd include Itch.io, much of Taobao, and some of the most popular API gateways (including Kong) in the category of "Internet-scale software written by 'people'".
- Performance: Requires nuanced tuning. Caddy performs competitively well for real world usage
- kTLS: Sacrifices memory safety.
- Existing modules: How do they perform compared to natively-compiled code? Caddy modules can do all that nginx modules can do, and more, but are natively compiled. I ran experiments with Caddy+Starlark that performed 2x as fast as Nginx+Lua.
I recommend users who link against OpenSSL to enable padding to multiples of at least 1024 bytes if they want to impede traffic analysis. The Nginx devs aren't interested in implementing random record padding or supporting the feature in BoringSSL/LibreSSL, unfortunately.
Can Caddy leverage either form of padding? If so, I might need to give it another look!
And regarding modules: most are written in C and dynamically loaded as shared objects or statically linked during compile-time. A bunch are listed at https://www.nginx.com/resources/wiki/modules/. The ones for live streaming and VODs are the hardest to replace, IMO. IPScrub was my favorite but I haven't used it for a few years.
Personally, I think live streaming and ffmpeg-based encoding are specialized enough to warrant a specialized server (like a custom Nginx build) and are a bit out of scope for a general-purpose user-friendly server like Caddy.
I'm not sure, I'd have to see what the crypto/tls package does.
I would push back against the notion that something like that is "out of scope" for a "general-purpose user-friendly server". Caddy is far from user friendly if you utilize its low-level JSON configuration API, and at its core, Caddy is an extensible server platform. Even its HTTP app is a plugin, and it can be extended to do frankly anything if you want it to. Streaming video is a use case that I know several people use it for already.
I tried it out on my own site, and through trial-and-error I found that Chromium does in fact treat the "max-bpp" Document-Policy directives as bytes-per-pixel.
I could be wrong; my memory has faded. Please correct me if this is the case.
I'm not sure what HTTP headers have to do with anything. Using "bpp" to mean bits per pixel is extremely common in image encoding. See e.g. https://en.wikipedia.org/wiki/Color_depth where an uncompressed image is often 24 bpp (8 bits per channel). It's also common to use bitrate (rather than byterate) in audio encoding, see e.g. https://wiki.hydrogenaud.io/index.php?title=Bitrate
Is 'Xe' the name or the preferred pronoun of the person in question? Is this like Latinx but race neutral? Gender identity accommodations seem to get more complex and confusing by the month...
[correction] on their GitHub page I see: Please call me (order of preference): Xe/xer, They/them or She/her please.
[edit] obscure to have your pronoun also be your name (or maybe your title?). Or maybe it is all just satire, given: "I am an ordained minister with the Church of the Latter-day Dude. This allows me to officiate religious ceremonies in at least the United States." - https://dudeism.com
To be honest having a person's name be the same as their nominative case pronoun is kind of cool from a whole different perspective than you normally get to see. By doing this experiment I get to see how bad of an idea it is to do that. So far the xe/xer pronouns don't seem to stick as well, but it looks cool so I'm gonna keep up the experiment.
> To be honest having a person's name be the same as their nominative case pronoun is kind of cool
The whole point of a person's name is to sufficiently differentiate them from the other persons. Using pronoun as name (or vice versa) just totally negates this goal.
To be fair, the name came first. Then I found out it conflicted with people's pronouns and I sat on the idea for a while. Now I'm throwing science at the wall to see what sticks, and this is a fairly amusing experiment. So I'm gonna keep it going.
Who gives. Just use 'they' or 'them', or whatever. It is a universal catch all, gender neutral, i18n inclusivity conformant, ISO 69420 compliant, race neutral, etc.
At this point, all of it is basically designed to further confuse and only create a very monthly chaotic outcome for everyone.
Xe has been in use as a gender neutral pronoun for nearly thirty years. I, a startlingly ordinary person, was familiar with it as early as the late 90s.
