Fucking firmware update broke NAT loopback

Firmware upgrade broke NAT loopback. And I can't downgrade the firmware. God fucking dammit. This is beyond frustrating. [I know it's a problem with the router because when I switch to my other router it works perfectly fine.]

I called my ISP and they told me they can't downgrade the firmware.

I called the manufacturer and they told me my ISP manages the firmware.

Fucking hell.

EDIT: Disabling express forwarding seems to enable the NAT loopback. I have no idea why the fuck this is the case, I'm 99% sure it's a bug, but whatever.

EDIT2: Disabling express forwarding seems to have had no noticeable impact on latency lol. I compared the latency with and without express forwarding and there is no noticeable difference.

EDIT3: Disabling express forwarding seems to have reduced my wifi speed down to 100mbps...fucking hell.

Benchmarking Map iteration in Go

So I was wondering how long it would take in Go to iterate over a map with 1 million entries:

func main() {
	Map := make(map[string]int)
	for i := 0; i < 1000000; i++ {
		Map[util.Int64_to_string(int64(i))+util.Int64_to_string(int64(i))+util.Int64_to_string(int64(i))] = i
	}

	start := time.Now()
	fmt.Println("Map size:", len(Map))
	for k, v := range Map {
		if v%5 == 0 {
			delete(Map, k)
		}
	}
	fmt.Println("Map size after deletion:", len(Map))

	elapsed := time.Since(start).Milliseconds()
	log.Printf("Iterating over Map took %vms", elapsed)
}

Turns out, only 50-70ms.

And for 300k items, only 15-17ms. Not bad.

I want type safe enums in Go

Man I can't believe it's almost 2024 and Go still doesn't have type safe enums. 

Every time I want type safe enums in Go, I remember that Go doesn't support them natively. 

It's so annoying to have to write all these boilerplate defining an interface with a method and then defining each enum as a struct with the method...it's so much boilerplate for what should be a relatively trivial language feature.

God dammit! When will Go get type safe enums!?!?!?!?

Further reading: 

• https://preslav.me/2023/03/17/create-robust-enums-in-golang/

Go gotcha: taking the address of an iterator variable

Today I wrote something like this code:

package main

import (
	"fmt"
)

func main() {
	var answer *int
	target := 3
	nums := []int{1, 2, 3, 4, 5}
	for _, element := range nums {
		if element == target {
			answer = &element
			fmt.Println("The answer is:", *answer)
		}
	}
	fmt.Println("The answer is:", *answer)
}

And of course it is incorrect. See if you can spot the bug.

Yes, that's right. Go reuses the iterator variable so it is incorrect to take the address of the element variable in the above code, since the value stored in it will change (it will be set to 5 by the end of the loop above).

See also:

• https://www.evanjones.ca/go-gotcha-loop-variables.html 
  
• http://tdongsi.github.io/blog/2021/07/24/closures-in-loop/
• https://www.reddit.com/r/golang/comments/13dr088/proposal_to_fix_gos_1_gotcha_loop_variable_scope/ 
  

It seems this issue will be fixed in the next release of Go (1.22) which is expected to come out sometime February 2024. I'm pretty excited for that.

As for the performance implications, I found this comment from rsc in that Reddit thread:

https://go.googlesource.com/proposal/+/master/design/60078-loopvar.md does say:

Similar code might change from allocating one variable per loop to allocating N variables per loop. In some cases, that extra allocation is inherent to fixing a latent bug. For example, GenerateTestIDs above is now allocating 10 int32s instead of one – the price of correctness. In a very frequently executed already-correct loop, the new allocations may be unnecessary and could potentially cause more garbage collector pressure and a measurable performance difference. If so, standard monitoring and allocation profiles (pprof --alloc_objects) should pinpoint the location easily, and the fix is trivial: declare the variable above the loop. Benchmarking of the public “bent” bench suite showed no statistically significant performance difference over all, so we expect most programs to be unaffected.

How easy it is to insert ads into HLS!

I was wondering how to insert a small 10 second advert into a 9 hour long video without re-encoding and I had this genius idea - just convert it to HLS, it will be a bunch of small TS files along with a playlist, then I just put my advert (a TS file) into the playlist and it will all work!

Unfortunately, that didn't work, but it turns out the fix is really simple: https://developer.apple.com/documentation/http-live-streaming/incorporating-ads-into-a-playlist

You just need to add the EXT-X-DISCONTINUITY tag and it will work just like it says in the Apple docs! So simple! Wow!