forcing many users to consider the unthinkable “Do I really need 300 subscriptions?”

Look on the bright side, it’s only 3,5 days of downtime a year.

https://uptime.is/98.98

Well, normally I’d agree but in this case I’d guess that more people have watched the video than read the blog. That’s the order in which I stumbled on it too.

Edit: Also:

I’m working more with older SBCs and microcontrollers now, and I think that’s the direction many in the hobbyist space are going.

In the embedded video he talks about it from 4:40-5, then talks about microcontrollers and mentions used hardware (though says it’s also affected by price hike).

Switched to self-hosted Forgejo already so now I’m just waiting for my dependencies to switch.

10 minutes ago my forgejo test failed because github returned a 502 for the home-manager repo •-•

For even more context: That means that 89% of the time all parts that make up github work without issue. 11% of the time at least one component has issues/downtime.

https://mrshu.github.io/github-statuses/ shows the breakdown, git push/pull operations for example have 98.98% uptime.

The thing that these complaints about RPi pricing complaints always seems to miss is that that was talked about in the blog.

Use a VPN, it’s not ideal but it’s secure.

When does your Server actually pull the repo though?

You’re not allowed to smile in those.

Are you sure you don’t need the lube?

https://f-droid.org/packages/com.amnesica.kryptey/

I have linkwarden set up for this.

On Android I share to the linkwarden app to save, on pc i use the Firefox addon.

Sure it’s fragmented but I’m already used to doing things different between mobile and pc anyways.

doesn’t cover ISP or commercial equipment

The foreign backdoors will stay for critical infrastructure

because all the other programs, protocol are working fine.

With the shown firewall configuration nothing but NTP should work? You’re dropping outgoing packets by default.

Update your nftables rulefile or use nft commands to update your firewall to the following:

# extract
chain OUT {
    type filter hook output priority 0; policy drop;
    udp dport 123 accept

    limit rate 3/second log prefix "Nftables Blocked: OUT: "
}

chain IN {
    type filter hook input priority 0; policy drop;
    ct state established, related accept

    limit rate 3/second log prefix "Nftables Blocked: IN: "
}

Blocked pakets will show up in the kernel log (dmesg/journalcl)

If you want more information on why it is blocked then enable nftrace for those packets

nft add rule inet/ip/ip6 tablename OUT udp dport 123 meta nftrace set 1
nft add rule inet/ip/ip6 tablename IN udp dport 123 meta nftrace set 1
nft monitor trace

Or

nft add rule inet/ip/ip6 tablename OUT meta nftrace set 1

Or maybe even

nft add rule inet/ip/ip6 tablename PREROUTING udp dport 123 meta nftrace set 1

Additionally you can use tcpdump -i <interface> to show network packets before they enter the firewall, there you should be able to tell what it’s a trying to do.

Successfully merging this pull request may close these issues.

None yet

Pro tip: If you’re using openwrt or other managed network components don’t forget to automatically back those up too. I almost had to reset my openwrt router and having to reconfigure that from scratch sucks.

If logging is down and there’s no one around to log it, is it really down?

That won’t work in most cases, all https traffic isn’t cached unless you mitm https which is a bad idea and not worth it.

Only cache updates those are worth it and most have a caching server option.