gurrone

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.

Might be noteworthy that in recent enough k8s lifecycle.preStop.sleep.seconds is implemented https://github.com/kubernetes/enhancements/blob/master/keps/... so no longer any need to run an external sleep command.

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.

Also an interesting option is using deb822 sources.list format and inline the key https://lists.debian.org/debian-devel/2021/11/msg00026.html

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.

The original video footage which belongs to the article series is frightening https://vimeo.com/136529193

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.

In 2019 someone from Elastic also tried to highlight the issue and various models at the market right now in a talk https://media.ccc.de/v/froscon2019-2463-open_source_as_a_bus... My main take away was "it's complicated".

Sad story is that in many cases the biz paying for interesting contributions is questionable (Googel, Facebook et al).

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.

Still they place FreeBSD running on prem hardware in the ISP PoPs as a caching layer because it absolutely makes sense. https://papers.freebsd.org/2019/FOSDEM/looney-Netflix_and_Fr...

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.

If you ever get to the southern Alps of Italy you'll find a lot more lost places barely accessible by foot, if at all. Also a lot of old mines, contraband trails and houses can be found in the area around Iselle close to the Swiss border. It's sometimes amazing what you see there, some of those abandoned areas will have 100+ houses (build by hand).

Just one stunning object among many: http://www.amici-del-leader.it/Home/Montagna/Le%20escursioni... (Villa Lancia, Valle Olocchia)

Edit: Maybe also entertaining for some, old stone pits where the Italian left everything behind in the mountain, including cars https://alpi-ticinesi.ch/foto/gallerie_foto.php?id=190&foto=...

I would like to add: Do they understand that it's impossible to delete anything that got commited to the block chain once a block is accepted? I mean at least if they think about a blockchain in the sense of the Bitcoin blockchain. Implementing a deletion of prior blocks is an interesting problem.

I see this is working for a constantly developing project like browsers. But imagine you just stoped to work on your side project for a year. Now you come back and would just like to add a new feature. You start with updating all your libraries and half of them started to introduce API incompatible changes (the author gave you at least 15 minor releases and three month of transition period but you did not pay attention) and you spent the next two days just with catching up on the development side of things. We did not yet look at all those bugs and security holes which were open in all the libs you used for the last year.

I see a similar friction here we also face between distributions and developers and the main issue for friction seems to be the friction about guarantees for stability. And only after that it extents to the friction about getting the latest version shipped to the user (either developer or end user of an application).

In corporate environments they claimed we solve this all by running microservices and we would just version our APIs to guarantee the stability of our interfaces to our fellow developers. I still would like to see this working for extended period of time in the real world.

I don't see how containers or flatpacks will solve it. At some point someone has to touch it again. Be it for bug fixes, security updates, feature development. If hell breaks loose everytime you've to continue stalled development because something wasn't as stable as expected in your ecosystem we've not solved the problem yet. And it's not solved if we install five different versions of a lib with different sets of bugs in parallel.

Might be interesting for some of you, Hauke from LEDE posted a few insides over at LWN: https://lwn.net/Articles/735316/ https://lwn.net/Articles/735317/

tl;dr updated packages of dnsmasq are currently building and should be available soon

I would like to add that you can usually in place upgrade from OpenWRT to LEDE. Though making a config backup and a backup of the list of additional packages you installed is highly recommended. Beside of that just flash and reinstall all additional packages.

From my own experience lifesize voice and video quality is so awful that anything from an egineering company should be superior. Also the stability of the lifesize appliance is horrible. Often enough we've to reboot them before every meeting, because the microphone went dead again. The only positive point is that it works with Chromium on Linux including the window sharing extension. I hope it's of slightly better quality then webex. But I fear that is overly optimistic at least.

On the other hand Google Hangouts is for free, has from my experience a better quality and all of them ship your data to the US. If amazon offers something similar they and can offer an option that keeps your data in Europe that would be an interesting option.

What is this constant rumor about that Google killed XMPP federation? I think they killed the XMPP support in their own clients, but in general they still provide the service. I've at least three active @gmail.com XMPP accounts in my roster on a private server. I've read some rumor that they do not do TLS for server2server traffic, but in the end if you use XMPP on your desktop you most likely use OTR.

Having started originally with Threema before I gave in to WhatsApp I kind of like the trust levels they established in the UI. Might be an improvement for the WhatsApp UI to downgrade the trust level visually in case of unexpected key changes.

Beside of that, and thinking through this comment by moxie, I fear he is right. I've a bunch of dead keys listed in my Threema contact list. All from people which are in general quite tech savvy but still were too lazy to transfer their keys on phone changes. And I already had to rescan (the QR code) quite a bunch of people when I meet them maybe once a year. Thats for my modest 20 something Threema contacts. Now think about the not very tech savvy average whatsapp user with his 150+ contacts. Maybe about a third of them will change their phone or MSISDN throughout a year. If you see 50 alerts per year in your chats that something changed, how long will you care to verify those changes that they're valid?

I don't like those defaults choosen by WhatsApp and once I knew about it I changed it. But at the scale of WhatsApp I understand the decision they made. You might also want to add the common argument that in the real world close to nobody will give a shit about the encryption. Since Snowden a few percent more care but it's still a small minority. So to bring at least some security to the majority that do not care is still a win. Everyone else has to make informed decisions about their own configuration.

I once thought we migrated most of the instant messaging world to Jabber. Now on the desktop side of things a lot of stuff switched to Hipchat, Slack, Skype and what else. On the mobile side of things we see WhatsApp, Threema, Telegram, Signal, Facebook with now some RCS thrown in between. Feels like we're back at the end of the 90s. And now fighting on two fronts for open networks. :( The only communication that stayed open all the time seems to be IRC and email.

Depending on the contract they do. Often enough it's the GSM modem paging someone for alarms that holds a SIM with some old corporate contract that has no flatrate. And you'd violate the contract if you exchange it for some private contract SIM with all inclusive SMS.