bajsejohannes

The decoupling of ingress and deployments always bothered me, although it might not be a _nightmare_ exactly.

In short, the ingress may route traffic to a pod after it is killed. The solution is that when a pod gets a SIGTERM signal, it should mark itself not ready, wait for some amount of time and then shut down (see e.g. https://deepsource.io/blog/zero-downtime-deployment/). I've heard arguments for this behavior, but it's not the same trade-offs I would make.

> Writing is a way of finding out

Writing _code_ is also a way to find out.

I really liked Linear Algebra And Its Applications by David C Lay, although it seems that more people dislike it. I believe it's a pretty common book for college intro courses. It does illustrate everything pretty well if I remember correctly.

Perhaps a game development book is even more visual? I haven't read it (yet), but this book is getting recommendations: https://gamemath.com/book/

That feels like it's underselling it a bit, since gdb does not have reverse execution, which is a pretty major contribution by rr.

It's telling that no professional stoves have capacitive buttons.

I definitely agree with the second paragraph. I got lost in tooling the first time I tried to learn FPGA. The second time, I got an iCE40 and used iverilog, flashrom and other open source tools. And it was extremely simple! Based on what I saw in the video (having to create a user just to download the software), I don't think FPGA manufacturers get this part.

For youtube specifically, I found this great snippet for ublock origin. It removes (almost) all recommendations in youtube, which makes it much easier to quit after just one video:

www.youtube.com###secondary

www.youtube.com##ytd-browse[page-subtype="home"] #primary

www.youtube.com##.ytp-show-tiles.ytp-endscreen-paginate.videowall-endscreen.ytp-player-content.html5-endscreen

Source: https://pawelurbanek.com/youtube-addiction-selfcontrol

When starting a greenfield project, the programming language will affect the culture quite a bit. At such a project, I chose C# because it's a reasonably good language and easy to hire for. What I found was that there's a culture of writing—in my opinion—overly abstract code. Our coding challenge could be solved easily in 50 lines of code, but most candidates would submit huge projects with dependency injection, type reflection, class hierarchies, etc. It was hard to create a culture of simplicity.

Now, this is highly subjective, but I think the general lesson applies: Programming language choice is important for culture.

Redis. The interface is quickly obvious using telnet (which makes all clients pretty obvious). The documentation is both succinct and complete. All operations are listed with their big-O notation.

Clearly someone looked at the competitor while building this page: https://imgur.com/a/q6kaD3q

Or `caffeinate sleep <seconds>` which has the (only) added benefit that it comes pre-installed with MacOS

Interesting. I wondered if it was related to the Norwegian/Danish "skive" [1], which means to cut or a cut of something.

[1] which could even be inflected like "skiving", though realistically it might not ever have

edit: of course, it might be that "skive" and "esquiver" are related...

Ah! I didn't think of that option. So the shift register keeps rotating regularly each frame and by timing it correctly, you can change specific bits.

First of all, thanks for all your blog posts. It's really interesting to see and understand actual die shots, not just understand it "in theory".

Secondly, how was the shift register actually used? Since every bit pushed in will result in one pushed out, wouldn't that force the input to be pushed in at the same rate as the output and thus the shift register just adds a delay? Or does it happen in two rounds, like so?

1. shift the screen data in and discard output

2. shift the screen data out at a different speed (presumably faster) while shifting in dummy data

Or is there a third option I haven't thought about?

Thanks! I feel like I actually understand that verilog code! Do you ever see the "rendered" state on the FPGA, or is that all abstracted away?

Would you recommend one of those FPGAs over another? I know iCE40 from this amazing project (https://github.com/nickmqb/fpga_craft) so maybe I'll just get that!

I've done so at two companies (without naming names). Not entirely, but enough to have a bargaining chip with AWS. At the largest company, our monthly bill was at least $1M at AWS, so the savings more than made up for the engineering time.

Also, in both cases, it was moving from AWS to GCP, and in both cases we were using Kubernetes and not really using much of the provided services of the platforms. I suspect this is the biggest reason for Google to push Kubernetes; abstract away compute so it's easier to switch.

Are you making your own softcores? Do you have a recommendation for getting started with that? I've recently gotten interested in making CPUs from logic gates, but I have no idea how to transfer that knowledge to FPGAs.

I once made a macro-lens [1] for a DSLR camera to serve as a microscope. You can do this by mounting a zoom lens the wrong way on the camera. It's a very fun project.

Anyway, a surprising thing I learned, is the very slow movement of things that appear stationary. For instance, we would set the subject on top of a book and some papers to get it to the right height. We used a long exposure time (maybe one minute?) to get enough light. And during that time, the book and paper would decompress and rise enough to blur the image completely. The solution was just to wait five minutes for things to settle.

[1] "macro", because it magnifies the subject as compared to the camera's sensor.

> Another thing is type-ahead. I remember in classic MacOS, people pressed shortcuts and started to type the filename or whatever. It was all perfectly recorded and replayed. In modern Windows, press Win-key and start to type, oops, it missed the first keypresses, presented the completely wrong results and made a mess of your workflow.

The arguably worst offender in MacOS these days is the emoji picker. Press ctrl+cmd+space, and depending on how recently you opened it, it can take some hundreds of milliseconds to open (on an m1). All while eating your keypresses.

I don't know, but it does seem self-contradictory to say it wasn't considered, because there's an implicit consideration in that, even if it's short lived.

SNOBOL4 on the other hand, was probably not considered at all.

Trailing off topic, but what's the static wikipedia mirror? I contemplated making something like that some years ago when wikipedia was quite slow.

> 64 bytes isn't that much overhead?

On the contrary, 64 bytes is a huge overhead. The standard maximum transfer unit (MTU) is 1500 bytes. So 64 bytes is 4.2% of the packet (at best!). Add the fact that you need a source and destination address, that's 128 bytes, or 8.5% of the MTU. Or, if you will, 8.5% (or more) of internet traffic, just in port numbers.

Maybe I'm misunderstanding the suggestion, but it would be a terrible idea to have 512 bit port numbers in TCP/UDP packets.

Very cool. One piece of feedback is that it took me an embarrassingly long time to figure out that "edit" was not selected. Since it's highlighted (in red), I tried to edit the circuit on the screen to no avail.

Personally, annoyances like this is enough for me not to want wireless headphones. My wired headphones work 100% of the time. It's obvious what they are connected to.

(PS, I also prefer transport belts over robots in factorio, and explicitly constructed objects over dependency injection in programming)

> Stuff to be able to talk to web services (because let's face it, any modern software will be doing that) is the obvious low hanging fruit, i.e. HTTP, JSON, Crypto etc.

The problem with adding this is that in 10-20 years it's not so useful anymore. Then you'd have:

* an outdated HTTP library (look at how "everyone" is using a 3rd party HTTP library in python)

* a JSON library no one uses (everyone used XML, now it's out of fashion. And JSON has obvious problems!)

* Old cryptographic standards that you'd rather not use

Spectre and Meltdown too. How much performance loss did we have to make up for because of that?

What I was imagining was the scene still being represented digitally with polygons, but the shader could still benefit from analog functions. Say, you could do functions like sine and logarithms faster/better/cheaper. So you'd get the same image, but with some added noise. Again, it's just pure speculation on my side.

That video was amazing, by the way!

Pure speculation ahead.

It doesn't have to be better in an absolute sense, but being good enough for a cheaper price, lower power usage, smaller footprint, etc.

I think a lot of floating point calculations could fall into this. For example in neural nets, maybe there are analog versions to calculate the weights, sigmoid function and so on.

And for graphics, you don't really need the exact color value of each pixel. Maybe those could be estimated in analog functions too.

In addition to what you're saying, it can also be _harder_ to watch something at 1x speed. I've found that at 1.25x-1.5x my mind is more engaged. If it's too slow, I start thinking about other things and end up getting less from the video.

Neat. I've been thinking that such a product should exist.

Are you sampling just a single point for temperature or do you get the maximum value of a bunch of IR-pixels?

Also, with your first dollars earned, I would hire a photographer for better product pictures :)