Man, it's been a few years since I've heard 'spiritual' people talk, and I did not miss it at all.

Das Gespräch war halt wie Schnackstunde im Altersheim. Einer, der irgendwie psychisch durch ist und ständig irgendwelche offensichtlichen Lügen erfindet, wie toll er sei. Und der andere, der dagegen hält, aber teilweise zu senil ist, um einen Satz zu vollenden.

Dass die beiden sich als Präsident der USA bewerben, macht es dann so richtig surreal.

Yeah, that is my understanding, too. Otherwise you'd only want to generate them on the database host, as even with NTP there will be small differences. This would kind of defeat the purpose of UUIDs.

If you're saying that even without NTP, just by manually setting the time, things will be fine. I mean, maybe. But I've seen it far too many times already that some host shows up with 1970-01-01...

For others wondering what's wrong with UUIDv4:

UUID versions that are not time ordered, such as UUIDv4, have poor database-index locality. This means that new values created in succession are not close to each other in the index; thus, they require inserts to be performed at random locations. The resulting negative performance effects on the common structures used for this (B-tree and its variants) can be dramatic.

I guess, this means with these new UUIDs, ideally you only create UUIDs on systems that are hooked up to NTP, though I guess, it won't really be worse than UUIDv4 either way.

My mum would iron everything. Then I moved out a few years ago. I still do not own a clothes iron.

It's certainly simpler than Forza et al, but there's an open-source racing simulator, called Speed Dreams: https://www.speed-dreams.net/
If you watch the "Latest Release" video, there's some engine sounds in that.

They seem to have a bunch of samples for how different car models' engines sound: https://sourceforge.net/p/speed-dreams/code/HEAD/tree/tags/2.3.0/data/data/sound/

And then they modulate that in code, based on the car's speed, gear, turbo etc.:
https://sourceforge.net/p/speed-dreams/code/HEAD/tree/tags/2.3.0/src/modules/sound/snddefault/CarSoundData.cpp#l171

They also do that for gear changes, tyre sounds, collisions and backfires.

From what I know about audio, I would expect AAA games to still use the same approach of recordings+modulations.
While it is possible to fully synthesize an engine sound, it doesn't help you much with making it sound right in all different situations.

With that name, I hope the guy is also a fan of Minetest: https://wiki.minetest.net/Mese_Block

🙃

Anscheinend nennt man Gluten auch "Klebereiweiß": https://de.wikipedia.org/wiki/Gluten

We've been using Leptos at work, which is a similar framework (and probably shares half the stack with Dioxus).

And yeah, it's really good. My favorite thing about using Rust for the UI is algebraic data types.
So, in Rust when you call a function which can fail, there isn't an exception being thrown, but rather you get a Result-type as return value.
This Result can either contain an Ok with the actual return value inside. Or it can contain an Err with an error message inside.
So, in your UI code, you just hand this Result all the way to your display code and there you either display the value or you display the error.

No more uninitialized variables, no more separate booleans to indicate that the variable is uninitialized, no more unreadable multi-line ternaries.
It just becomes so much simpler to load something from the backend and display it, which is kind of important in frontend code.

It's not a dual-language platform, though. You write the backend and the frontend in Rust. The frontend code is compiled to WASM to serve it to the browser.

It's a format published by Google without much industry input. I imagine, that's why it isn't seeing terribly much adoption.

AVIF and JPEG-XL might do better, but they're still relatively young formats.

Yeah, GIF is an extremely old format and rarely used these days. You just still see files being called ".gif", even though they're APNG or MP4 or something else under the hood.

Achso, ja, die Katholiken verstehen sich nicht als Vegetarier, aber wenn die freitags in Kantine/Restaurant oder irgendwo zu Besuch sind, dann wird eben angemeldet, dass sie kein Fleisch essen, obwohl sie Fisch trotzdem essen.
Bzw. oftmals müssen die das nicht anmelden. Hier in der Kantine gibt's immer freitags Fisch statt anderem Fleisch.

Naja, und jetzt meldet man als Vegetarier genauso an, dass man kein Fleisch isst, und dann fragen sich die Leute eben, ob da Fisch auch dazugehört.

Making the API version a feature flag is a very interesting idea.

Fading out? With my wind band, we've never done it.
You can have everyone play pianissimo and also reduce how many players play each voice, but unlike a digital fade, this does change the way it sounds.
It's also difficult to stay in tune when playing at a low volume with a wind instrument, so it starts to sound horrible before it becomes inaudible.

@[email protected] mentioned mic+soundboard, but for a windband, the band itself would need to be out of earshot, which is rarely possible.

So, yeah, if we ever need/want to cut a song short, we make use of a marching band signal.
Basically, the person on bass drum does two double-hits, which are out of rhythm so you can hear them, and then another hit on the first beat of the next measure, which is when everyone stops playing.
That does not always sound great either, but better than nosediving the whole orchestra. 🙃

Ich denke, dass das hauptsächlich von den Katholiken kommt. Da gibt's eine Regel/Empfehlung, dass weil Jesus vermeintlich an Karfreitag gestorben ist, dass man jeweils freitags, sowie in der Fastenzeit vor Karfreitag, kein Fleisch essen soll. Fisch ist aber eben erlaubt.

Excuse me, Windows is the cheap copy of KDE.

I always hated that. It always felt like they just admitted defeat. They could have made an excellent song, but settled for disappointment.

Now I'm doing music myself, and goddamn, I get it. You can have a cool song going, and then you try to end it and it just sounds like disappointment every time.

Decent video, except for the rant on post-quantum cryptography. That is a real thing and a real concern. Zoom did not come up with it.

Basically, traditional cryptography gets a lot of mileage out of the principle that multiplying two primes is easy, for example 13*17=221, but figuring out from which two primes 221 was multiplied from, that's hard. As in, you just have try dividing it by random primes until it divides cleanly.

Sufficiently powerful quantum computers will break that principle, because an algorithm already exists for them, which makes it so you don't have to randomly try anymore. This algorithm is called Shor's Algorithm.

So, we also know the solution to this problem, which is to pick another such one-way calculation to encrypt your stuff. Elliptic-Curve Cryptography is most prominently used here.

It certainly wouldn't need to be Zoom's top priority and there's no guarantee that we won't have algorithms to also break ECC when quantum computers come around. But this one was already solved "down the stack", so it was easy for Zoom to implement. And plugging the future holes we do already know about, is still good.