The film is centered around the idea of establishing an alternative to the GDP as the metric to measure success of a country/society. The film follows mostly Katherine Trebeck on her journey of convincing countries to look beyond the GDP.
Since it's quite hard to view such independent movies this is a rare occasion to view it online in a virtual screening. This screening is organized by the Permaculture Institute and donation based!
Hint: There is another screening one day later in case you miss the one the 29th.
That is only partially true. So you spin up a GKE cluster, setup your deployment push it out via kubectl. OK your app is running but now you need access to it. The portable way is a Service Loadbalancer but it's just a TCP loadbalancer. So you go for the Ingress API. Then you want to do it a little bit more, you learn that the Ingress controller on GKE just configures you a L7LB at Google. Nice, that can do what I want. I want it to run dual-stack IPv4 and IPv6 (my prior example for those shortcomings in GKE was setting response-header but that was added lately after only 3yrs). Oh snap supported by the LB but not by the Ingress controller. Then you dig deeper and learn that development already shifted from the Ingress to the Gateway API. And now you're already knee deep into problems, because what you want to do is not really part of the Ingress or Gateway API and now you're at the mercy of the vendor you choose. Or you run a vendor neutral Ingress controller, like the classic nginx one. That later choice means you've to make yourself familiar with the oddities of that component as well. And then you also want something for DNS, Let's Encrypt and so on. Half a dozen controller installations later you finally have something. But now you've to maintain it because the managed service is only for k8s.
But one should not forget that you also had to build up a lot of vendor specific know how in the past. Someone had to configure your F5 BigIP and your Juniper Router and the Cisco Switch and of course the Dell or HPe boxes you bought.
I take more concerns with k8s immature ecosystem which is kind of reinventing classic unix stuff for distributed computing. And that just started and you've to lifecycle components with breaking changes every few weeks. And people took issues with updating Ubuntu LTS releases every two years. Now they have to update some component every week.
... and mrsk is imperative compared to the declarative approach of swarm and k8s.
Especially if you go all in on gcp and use gke + config-connector + fluxcd or argocd and all the other controller, it takes time to know and understand how successful your latest change was. In the end k8s + controller is a huge asynchronous reconciliation loop. It might succeed to apply your changes at some point in time, but you've no idea when it starts and when it ends. That often sucks and takes a lot of time. And even more time if you've to figure out which change failed and why and if it's the final state already. Some older dudes with grey hair might remember cfengine and its eventual consistency approach.
That just made me look at Google Cloud again, and it's depressing to see.
At least some types of load balancer do support dual-stack setups, but not if you configure them via GKE with the k8s ingress controller. If you use that one you're out of luck and they maybe now implement it for the new gateway API controller.
So if you use GKE and ingress you can configure two of them. One with a static v4 address and another one with a static v6 address. Of course you pay twice then.
Would use OpenBSD + unbound to get NAT64 + DNS64.
I'd prefer a dual-stack setup with RFC1918 IPv4 internally + a NAT44 gateway and IPv6 "just" on top.
Drawback: if you find yourself to have to do a lot of firewalling it essentially doubles your work.
20 years ago it was the lack of IPv6 support on the CPE holding IPv6 on the server side back, nowadays it's a lack of IPv6 at major SaaS providers causing issues. In most of the scenarios I was involved in we made sure that the CDN in front of the product was able to terminate IPv6 and left everything behind it v4 only. About 1/3 to 1/2 of the traffic received was sent via IPv6 on those setups. Maybe time to turn that around and use the CDN to make the product also available via v4?
Leaves you with maintaining a NAT gateway for your own infrastructure.
BTW also only one of the office networks I had to deal with in the past 20 years hat experimental IPv6 support, and that was at a small local hosting company. Everything bigger than that also sticks to IPv4 only for now. :(
Strange how things change but still stay the same.
Same if you're lead climbing, there is a small chance (if you left a longish tail end) to clip the wrong part of the rope. If if it does not directly result in a dangerous fall you might trap yourself inside a quickdraw.
Ironically I lately had a payment service provider handing me newly generated ecdsa ssh keys where ed25519 should be supported to the best of my knowledge. And fluxcd moved from rsa to ecdsa by https://github.com/fluxcd/flux2/releases/tag/v0.21.0.
Kinda strange people are moving on to EC cipher - which is good, but to the cipher which has the NIST/NSA smell.
Still a bit ugly depending on the point of view you take but a 3rd party vendor can just tell the user to download this file and store it in /etc/apt/sources.list.d/
which should make that whole thing a bit more frictionless.
Bitbucket has it as well. When you move from Bitbucket to Github your PR workflow in the WebUI feels utterly complicated and way harder to review.
I already started to use gh a few month ago and that finally puts some sanity into working with github. Beside of creating PRs and merging them you can also get the diff of the PR, and pipe it to other tools. In the most simplistic case into diffstat. That finally compensates a bit for the horrible WebUI experience. Still a tree view would be nice.
Well still the default mta on Debian, so it has some userbase, at least as a local mta. Might catch some by surprise, but maybe those systems should not have had direct exposure to the internet in the first place.
I find it amazing how often ad blocking is discussed here, and start to wonder how many peeps hanging out here on the other hand depend indirectly on ad revenue to pay bills?
There are obviously the big corps Facebook and Google, but also my own small employer, which is in theory in a different biz, runs ads on the web shop as an additional income source (which I find not very clever, increases page load times and is simply not our core biz). Do we all pay our bills with money made from the pour souls who did not get around to install an ad blocker or advanced setups like a pi hole?
I'm on the pro ad blocking camp personally, also worked in the past in a biz that was 100% ad financed for a short period of time. Also there the whole tech department was using ad blockers.
Yes it's trade off as usual.
The main benefit I see is on networks where you've a mix of good and bad traffic and you would still like to offer the service to the few good users.
I see this a lot on networks hosting a lot of free VPN providers. The other option we choose before was outright blocking. That is even more harmful for the few good users.
I guess this is very true. Our quite elaborate Cloudflare Firewall setup combining bot management scores with GeoIP and network information to decide on the action has solve rates below 0.5% on most rules.
The only case where we see up to 3% solved is on rules targeting networks which contain mostly free (as in beer) VPN providers (the new pest of the internet). Those networks sent a lot of malicious and automated traffic with the mixed in 3% of real users.
To put this into numbers of the past 24h:
~ 76 Million requests served
~ 1 Million of those were captchas
~ 0.5 Million were outright blocked
Captchas solved: 1233
Yeah recent credential stuffing attacks I witnessed showed that blocking traffic based on AS numbers is very helpful.
If your attacker is stupid User-Agent based blocks can be surprisingly effective as well. Beside of that rate-limiting, and if you can, geo blocking can at least slowdown malicious traffic.
It's a bit of pity that the internet is no longer a peer2peer network and just client-server. But since you've a lot of server only networks, you can quite safely block them if your API is clients only. You still might see some false positive due a lot of VPN provider traffic. For what it's worth free VPN services now also push a lot of malicious traffic.
nginx behaves RfC conform. So if you sent it a SIGHUP it will try to respawn all workers by closing (from the server side) all open connections. The problem is that this behaviour confuses some HTTP libs/connection pooler more then others. For example OkHTTP seems to be able to deal with it, but others not so much.
Once you reach like 6-12 reloads per second you run into latency issues because you've to establish a new connection for every request, and if you're still running with HTTP/1.1 every benefit of idle connections and connection pooling is defeated.
Examples like Traefik (or more old school the F5 BigIP LTM) split frontend and backend handling of connections, and deal with so many reloads more gracefully. Beside of avoiding issues with HTTP libs it at least improves your latency.