v1ne
Joined 3 years ago
Joined 3 years ago
If the mapping between the logical and physical interfaces changes, that probably means that your NICs lack proper IDs to differentiate them or the bus topology is somehow not stably sorted. I wouldn't blame the OS for this.
Negative example: I was looking into the German manual of my Canon EOS R5 II, and it is just fluff. Hundreds of pages, full of white space, telling me about features without actually explaining what they mean. Awful automatic translations. Their manuals used to be good (looking at my EOS 6D). But these days: oh boy.
I don't know, does Resolve have lens corrections for 100+ lenses built-in? That's the thing that DxO does really well: Lens corrections, matching your camera's color rendering, denoising. Unfortunately, they still struggle with HDR output.
I imagine the tools in Resolve save you much time, due to automation. Probably handy if you shoot a lot. Yet, the biggest difference is that in photography, you're not necessarily limited by throughput. You can and do actually put a lot of effort into single images.
TBH, I didn't watch the video because the title is too click-baity for me and it's too long. Instead, I looked at the benchmark results on the Github page and sure, it's fascinating how you can significantly(!) thin the latency distribution, just by using 10× more CPU cores/RAM/etc. Classic case of a bad trade-off.
And nobody talked about what we use RAM for, usually: Not to only store static data, but also to update it when the need arises. This scheme is completely impractical for those cases. Additionally, if you really need low latency, as others pointed out, you can go for other means of computation, such as FPGAs.
So I love this idea, I'm sure it's a fun topic to talk about at a hacker conference! But I'm really put off by the click-baity title of the video and the hype around it.
The formatting is strangely inconsistent, highlighting only some numbers and some variables in fixed-width font. Also there's odd statements like that the reference resistor keeps its value "at all temperatures", which is just not true. Other phrases like "poly-silicon resistor" are highlighted, and then not explained. All in all, I find this article to be quite a mess and not a clear explanation.
On Windows, the window will adapt as you move its center of gravity across the edge of the screens. Sure, could be better than at the moment where the window is the wrong size, but it would always be blurry.
Also, there is nothing complex in a C compiler. As students we built these things as toy projects at uni, without any knowledge of software development practices.
Yet, to bring an example for something that's more than a toy project: 1 person coded this video editor with AI help: https://github.com/Sportinger/MasterSelects
Fast forward to now, after being a dev on Windows for years and loving it, and now their UX is a joke. For example, to jump back and forth between chats, neither the back/forth mouse buttons nor any other key combo works on macOS. You have to click the navigation buttons in the symbol bar instead. Translations are AI-powered, and that shows. Also, Teams is dog slow, which I also count as a UX issue.