jbergstroem

The client hints draft is somewhat helping here (10 years later): http://httpwg.org/http-extensions/client-hints.html

For record-keeping: got a reply two days later from support saying that they do not support sending notification emails, which this is classified as.

What ToS am I violating exactly? I’m _well_ within limits for both incoming and outgoing and all recipients sign up for receiving the emails. The gitlab wiki even uses fastmail as an example for smtp.

I'm just now experiencing the direct opposite with Fastmail. Used it to avoid setting up my own mail server for a ~50 user gitlab instance. Went from trial user to paying for a full year and one day later my account is now blocked. Found this message in the first rejected email: "We couldn't figure out what the email is for. Please create your issue or comment through the web interface.". Can't send mail through webmail interface. Can't access IMAP nor SMTP. Support emails from their own support doesn't go through.

So, without any means to control it myself I'm now in the mercy of fastmail support unless I set up my own postfix/dovecot in the meantime. I guess it goes both ways.

The upstream repo from google hasn't been updated in over a year; issues are being opened questioning maintainership. It additionally breaks against more recent version combos of nginx/brotli.

There's an active fork here (which I also use on my remaining nginx instances) https://github.com/eustas/ngx_brotli

I've recently spent more time using H2O over nginx, mainly because of its more complete support of HTTP 2 (push, cache-aware push, ..) but also out of the box support for brotli compression and mruby (think lua landscape for nginx). Even though nginx made it easier to build and ship third party modules separately, I feel like the module community (as well as distro maintainers/packagers) haven't followed suit. There's obviously pre-baked packages like openresty which has lua world, but then there's no brotli.

For people that have tested it: can it set up connections over ssh tunnels? Would be a handy step to skip

Better put. As an aside: the headset and gun exists (https://www.wareable.com/vr/starvr-headset-review). The location soon exists with enterspace vr: https://www.enterspacevr.com

Speaking of good demos, I thought this demo-ish from the Starbreeze "AR/VR" was stack pretty cool": https://www.youtube.com/watch?v=x32FHiJJyhQ

Not sure how how wide their product will spread though..

[disclaimer: I own shares in the company]

My most common pattern is "Siri, remind me to ____ when I get home". The geolocation-"awareness" really hits my soft spot.

Perhaps add Apache Traffic Server for completeness!

It's usually extra hostile for things like caching. I've (on multiple occasions) seen one URI endpoint, http posts and method as a separate header. Pretty much as far away from a sane caching best practice as you can go. Also; a lot of these older web services doesn't support deflate, gzip (accept-encoding, vary, ..) so your average responses are 500kb and up. :'(

In a recent project, a client saturated their wire as a result of just this.

What made me post the link was that it – disregarding its debatable pointlessness – showed a diverse set of methods and tools that are useful in android packaging.

You might find IINA on macOS refreshing: https://github.com/lhc70000/iina

(note: I understand that linking to other software might come off as offensive, but I truly feel there is a place for both. VLC is pretty much irreplaceable for many, many things)

For that I reckon you'd have to file a bug with golang.

This could be a useful way of exposing your local dev (or ci) server for testing via third parties. Seeing how Argo will be required it is likely not for all users.

I find the haproxy (alpine) Dockerfile a great example on how to tender to container file-size. It uses the syntax you're referring to, temporary build virtuals (should be multistage today I guess) and static linking: https://github.com/docker-library/haproxy/blob/2d393f2b59824...

On the same note I did a mariadb container that is ~12mb: https://hub.docker.com/r/jbergstroem/mariadb-alpine/

If you're into go, it's not too hard to get very small (<5mb) shippables by statically compiling against musl and using upx. Here's a somewhat scrubbed Dockerfile for a gRPC/rest service I use at work: https://gist.github.com/jbergstroem/680cb7db6f90319dcd7666f3...

I would fit in the same category of users like you. I've been using micro for a few months and I find it a very pleasant experience. My downsides so far are: haven't found a way to disable the somewhat aggressive mouse control, haven't found a way to disable coloring background (slow rendering on remote ssh) and paste buffers being messed up in recent releases. I just opened a 500mb csv which arguably was slower than using vi/vim but still fast enough and snappy after the initial load.

Thanks! I'll keep this in mind.

Does anyone know of a way to help DDG improving by passing them statistics about how I use !g as well as passing information about the results I prefer from google? I can only assume it would be riddled with privacy issues but would be happy to occasionally provide it.

My preferred solution is letting "robots" do the actual rebase back to master. In my GH repo I set a label that says 'ready to land' which means that the last CI run will assume that done stuff like proper commit messages and have reworked my commit into how I want them (atomicity, etc). If for whatever reason tests, the extra validations and ultimately trying to rebase to master doesn't pass I get notified as a PR status.

I like the separation between having full freedom in a feature branch without the extra hassle of having to consider timing (active repos usually suffers from this) or typo:ing in commit metadata.

...if you choose to modify the yue source code and not redistribute it.

Definitely! Sane defaults and config readability is pretty much the main reason I recommend nginx.

I thoroughly appreciate how the majority of the article doesn't even go into the nginx config whereas most of the internet would discuss a result of the search query "optimized nginx config". Much [for me] to learn and much appreciated, Alexey.

Ran into the same issue with the mysql docker container which ultimately bothered me into making my own. Started off experimenting with trapping signals (trap foo INT,..) similar to the article but found this nifty `--gdb` (nowadays `--debug-gdb`) flag to mysqld that enables more signal handling.

Source: `docker pull jbergstroem/mariadb-alpine`

edit: docker should really open the doors for a cleanup/shutdown phase. There's both entrypoint and cmd but not a "exit" command.

Just because something exists doesn't mean one has to care. The problem with "frontend fatigue" is similar to what we see elsewhere; caring about problems one doesn't have or own in the first place. I'm not addressing you specifically (as your comment seems more observatory) - but I reckon it's still worth pointing out.

Let the curious create and share their creation with the world.

The same reason the Go 1.9 changelog won't be discussed in political forums, opinions on USA's political landscape surely has a better home on the Internet than here.

For me, plex is kind of this love-affair-product-turned-into-company based on unique insight into the home media experience, years before any other. I'm sure the founders and employees were passionate about what they did. And still are.

At the same time, they seem more disconnected to users than ever. In comments below/above you can witness the testament of their support. In their "feature request" threads you can see tens of thousands of (plex pass) users voting for something they feel important and have felt so for years (when the issue was opened) with no parseable reply. Put simply, their priorities (read: release/feature strategy) seems to be based on marketing impact.

I admire them for their insight into market as well as a lot of technology made look simple; like ssl for everyone[1] and a "just works" media scanner. It's just hard to see the forest these days.

[1]: https://www.plex.tv/blog/its-not-easy-being-green-secure-com...

I think this can be ok. It's pretty obvious that the Webdriver protocol was insufficient. Let browsers "take it home" for remodelling and see if a new standardization effort will happen down the line.