(Justin)

Tech nerd from Sweden

  • 1 Post
  • 111 Comments
Joined 1 year ago
cake
Cake day: June 10th, 2023

help-circle
  • I’m using IPv6 on Kubernetes and it’s amazing. Every Pod has its own global IP address. There is no NAT and no giant ARP routing table slowing down the other computers on my network. Each of my nodes announces a /112 for itself to my router, allowing it to give addresses to over 65k pods. There is no feasible limit to the amount of IP addresses I could assign to my containers and load balancers, and no routing overhead. I have no need for port forwarding on my router or worrying about dynamic IPs, since I just have a /80 block with no firewall that I assign to my public facing load balancers.

    Of course, I only have around 300 pods on my cluster, and realistically, it’s not really possible for there to be over 1 million containers in current kubernetes clusters, due to other limitations. But it is still a huge upgrade in reducing overhead and complexity, and increasing scale.






  • 1:1 stateless NAT is useful for static IPs. Since all your addresses are otherwise global, if you need to switch providers or give up your /64, then you’ll need to re-address your static addresses. Instead, you can give your machines static private IPs, and just translate the prefix when going through NAT. It’s a lot less horrible than IPv4 NAT since there’s no connection tracking needed.

    This is something I probably should have done setting up my home Kubernetes cluster. My current IPv6 prefix is from Hurricane Electric, and if my ISP ever gives me a real IPv6 prefix, I will have to delete the entire cluster and recreate it with the new prefix.


  • 1, These days the machines used to etch chips (flash light onto the chips to carve them out) are mostly made by ASML. The most modern machines are the ASML Twinscan NXE and Twinscan EXE. The raw silicon is coated with different chemicals that react to light, and when the light patterns are flashed onto the silicon, it carves physical arrangements of atoms on the silicon that forms complex electrical circuits.

    1. CPUs were literally drawn by hand, and then the drawing was shrunk down with a magnifying glass back in the day. Programs could be written into electrical memory with physical switches (think 100 light switches), punch cards, or electric typewriters. You could pause the computer so that it would wait for you to type in the next program for it to run. By the time we had kernels, we already had large memory banks in the kilobytes that could store the OS between program runs. So you’d type in the OS once when you turned on the computer, and it would keep in in memory until you turned the computer off again.

    2. The internet is different computers connected together. This website is just data sitting on a server somewhere, and your computer connects to the server over the internet and asks for the data.

    3. Everything is built on the shoulders of giants. There is plenty to learn, but there will always be something you don’t know.

    4. There’s tons of information online if you know where to look. There’s also some good courses out there to understand more specific things like cpu design, networking, programming, etc. In university these sorts of questions fall into the field of Computer Engineering, if you’re looking for a university program to get into.

    With regards to the limits of programming: Making websites is already challenging enough, but the cutting edge can be rewarding too :) Software Engineering is a massive field with infinite opportunities. Start small and work your way towards more complex projects with larger teams.

    Here’s a good 20 minute video about the history of making microchips: https://youtu.be/Pt9NEnWmyMo



  • This is a really important principle of making APIs that people don’t really talk about. There’s a fine balance between hardcoded literals and full-gui options menu.

    Every piece of data in your program has a different level of configurability, and you need to make that trade-off to decide how hard or easy it should be to change. You could hardcode the data as a literal, or you could hoist it to the top of your source file as a const. You could have a separate static const configuration class, or you could have a runtime configuration file. You could even go for an interactive configuration editor/ options menu. It’s all a tradeoff based on offering your users choice but not overburdening them with it, as well as balancing development cost.












  • The goal is to take the car as little as possible. It sounds like visiting the beach and visiting your friend isn’t possible without a car, and that’s not something that you need to worry about. If there are car sharing services available in your city, like zipcar. You can still do that without committing to the $10k/year cost of owning a private car.

    Let’s say you use a car 3 times a week, twice to visit friends, and once to go to the beach. Zipcar offers a $11/hour rate, and we’ll assume you spend 4 hours on each trip. That comes out to $132/week, or $6870/year, saving you over $3k/year over owning a car. You’d no longer have to worry about maintenance or car insurance. This would also be much better for the environment, since you can use a shared car instead of dedicating a car to yourself. Any week where you don’t go to the beach, or your friend visits you, would be pure savings for you, too.

    This video is a really good video about why car-sharing is so useful:

    https://youtu.be/OObwqreAJ48

    Source for $10k/year number:

    https://newsroom.aaa.com/wp-content/uploads/2021/08/2021-YDC-Fact-Sheet-FINAL-8-9-21.pdf