cyber_kinetist

Support Vector Machines involve solving a large QP optimization problem... which is often done by running a variant of gradient descent (or one of the second- or quasi-second-order optimization algorithms, which involves finding the Hessian as well as the gradient)

At least the Chinese AI companies are doing good service open-sourcing their models back to the public.

There is a real danger if Valve ever gets sold in bad hands - the only hope is Gabe Newell living long enough or find a good successor who can continue having a majority stake in the company.

The "no A, no B, no C" pattern is a phrase that's frequently generated by Claude Code.

Most progress in data-driven robotics nowadays are done either in unicorn startups or corporate research labs - so you should follow the industry more than academia. The path to good robot performance isn't really in the models themselves - it's highly dependent on how much you can gather high-quality real-life data.

Specifically for laundry folding, Sunday Robotics is probably the state of the art, where they were able to obtain 99.1% success rate and call it "done": https://www.sunday.ai/blog/act-2-preview#solve-standard

Which counteracts with the EU's desire to have any kind of sovereign AI. Guess you have to lose something if you want to earn something...

I've read both, but Baudrillard is more lucid and insightful in his writing. I would suggest reading Symbollic Exchange and Death (his magnum opus) instead of Simulacra and Simulation first though.

It has been a while since bro has become a gender-neutral term, particularly in younger circles...

Rust is slow to compile, and not that productive when writing gameplay code (see https://loglog.games/blog/leaving-rust-gamedev/)

Odin... technically not a scripting language, and haven't used it that much. But if compile times are good enough and hot reloading works, might worth a try. Though I think manual memory management can be antithetical when churning out gameplay code quickly (or when you're working with game designers with minimal background in programming)

Niche as in... I haven't heard anyone using it except for the studio that made it (Gaijin Entertainment). Might be a good language (at least from what the docs suggest), but needs some marketing to increase adoption...

For gamedev scripting, the gap has not been filled yet. Lua is good for embedding but the language itself is terrible for LLM usage (too much dynamic typing). C# is too heavy for scripting usage (long compile times, clunky to embed into a C++ engine), and other alternatives (AngelScript, daScript, ...) are just too niche.

There was an even better version of GJK published around 2017 which made it more numerically robust: the Signed Volume Method (https://dl.acm.org/doi/10.1145/3083724) OpenGJK is written by the same author, and is based on that paper.

Nope it uses modern OpenGL and LWJGL bindings under the hood. Recently they're in the process of switching the entire thing to Vulkan.

Note that I've used the term "Graphics Programming" rather than just "Computer Graphics".

The RTR book doesn't teach you the programming side of things at all, the material is more theoretical and reads more like a reference book. Most importantly it doesn't have any examples with full source code, so it's not a friendly book to follow for beginners. The PBR book is much better in this regard, but it mainly focuses on offline ray tracing / path tracing which is bit of a distinct topic from conventional real-time rendering on the GPU.

Nope, the limitations are just too huge for actual usage. Heard Godot Engine tried to use MoltenVK for macOS but experienced too many issues so they just developed a Metal backend.

The fundamental problem is Metal 3 is just too high-level to be able to emulate all of Vulkan's behavior. The new Metal 4 API (which is more low level and similar to Vulkan in many ways) might have improved things recently, but sadly MoltenVK hasn't been rewritten to this new API yet.

I think the dark side of OpenGL for beginning graphics programming is that debugging can be really frustrating! I really think learnopengl.com should have a mandatory section for how to use RenderDoc (https://renderdoc.org/) - it's night and day if you know how to use it.

DX11 suffers from the problem that there aren't that much high quality material comparable to learnopengl.com - I really don't like RasterTek which just dumps code at you without explaining things properly. Same for Metal - the best way would be to just download and read the example source code from the official Apple site, but it's rather unfriendly for beginners.

I think if you're trapped in the Apple ecosystem then Metal is your only production-quality option. But beginner-level learning material for it is quite sparse, so it's better to transition from OpenGL to Metal rather than learning Metal from scratch. (If you're an experienced graphics dev, you should be able to follow up on Metal by just reading their example source code)

Android smartphones are notorious in having low-quality Vulkan drivers full of bugs and spec violations... (I'm looking at you Qualcomm!)

A data point: SDL3-GPU maintainers announced that they will not give a shit about Android support, since there's just too many devices that haven't properly implemented the Vulkan spec. (https://github.com/libsdl-org/SDL/issues/12652#issuecomment-...)

Another data point: the current maintainer of the renderer portion of the Godot engine suffering through all the bug reports from Android devices (https://github.com/godotengine/godot/issues?q=is%3Aissue%20s...)

> I'm working on a "Post-Modern OpenGL" tutorial that exclusively teaches the most "modern" (merely a decade old) APIs and practices of GL 4.6. But, writing is slow going...

Is it the AZDO stuff? Quite interested, since there isn't really much information on the Internet about it rather than some slides and GDC videos.

> If you're looking for fundamental material, the last thing you want is learning a very (not slightly) outdated and weird API.

I've never seen a more detailed tutorial than LearnOpenGL that actually goes through the concepts of graphics programming thoroughly and actually make things other than just "learn how to use the API". That alone should be enough to cement the site's longevity.

> And OpneGL is worse

It's never late to learn Vulkan / DX12 after learning learnopengl.com! The value of learnopengl.com isn't in the APIs, it's about learning the basic concepts of graphics programming. If you start learning with Vulkan without any prerequisite knowledge, you'll be bogged in low-level details from the start that isn't really related with learning the actual fundamentals. (And you'll probably have to unlearn Vulkan and DX12 again once a new API has surfaced)

The one and only Holy Bible of Graphics Programming. If you're starting to learn computer graphics, just study through the entire site and do the examples one by one. It doesn't matter one bit that it uses a slightly outdated API called OpenGL - you're supposed to learn how to render things first, not about some weird obscure hardware / driver details!

After you've learned it, you can start learning CUDA if you want to do some more low-level compute stuff on the GPU (sorry, but you should just buy an NVIDIA card, CUDA is just that good). Or if you actually want to just make things but want to use a nicer cross-platform graphics API than OpenGL, then I recommend SDL3. (Or use Metal if you want to make macOS exclusive apps - it's actually a quite nice API)

Vulkan or DX12 are currently flawed APIs that are unnecessarily complex and doesn't even match the performance characteristics of current-gen hardware anymore. (see the titular post: https://www.sebastianaaltonen.com/blog/no-graphics-api). However if you want a computer graphics career (either in the game industry or in other niche domains) having experience with these APIs will be beneficial since these are what many production apps are currently stuck with - though honestly the job market for graphics really suck nowadays. (The biggest sector was triple-A game companies with their own engines, but the game industry is imploding right now...)

If you want to use glBegin() / glEnd() - like immediate API with modern OpenGL, I reecommend using a library called RLGL (https://github.com/raysan5/raylib/blob/master/src/rlgl.h), from Raylib. You'll feel straight at home!

In 2026: Yes yes, please please learn this if you're beginning computer graphics. This is basically the One and Only Holy Bible of graphics programming, and dealing with a slightly outdated and weird API doesn't make it worse even a teeny bit. You will never get the same quality of fundamental education material from any of the other tutorials (especially Vulkan ones, since most of them assume you already know the basics and delve straight into writing thousands of lines of code that doesn't even perform better than OpenGL). You need to first learn the really basic things like homogeneous coordinates, matrix transforms, vertex and fragment shaders, various shading models like Phong and PBR, multi-pass rendering, etc, before actually diving into lower-level details where you want to optimize things.

Vulkan and DX12 are currently flawed APIs that are unnecessarily complex and doesn't even match the performance characteristics of current-gen hardware (see the titular post: https://www.sebastianaaltonen.com/blog/no-graphics-api) - if you want to really learn the low-level details you should start diving into something like CUDA or get into graphics driver development (start by reading Mesa open source driver code - which you will then learn why Vulkan is flawed)

I think the main issue is that Bun relies heavily on existing C++ libraries like JavascriptCore, and these require RAII and ref-counting semantics from C++ that are closer to Rust than Zig.

You could write a JS engine with Zig-like idioms (arena allocation, static initialization), but that would require re-writing the whole JS engine from the ground-up (though I would definitely be interested in it if someone actually tries to do it!)

If both parties are actively willing to do it anyway, then why do votes even matter?

The art of Unsafe Rust is marking the right demarcation with the right set of invariants that Safe code must adhere to inside the module that uses Unsafe. If you do this incorrectly, then even Safe code outside the unsafe block can cause undefined behavior.

Which is why having unsafe code without exactly specified invariants is practically useless: the Bun rewrite code has too many SAFETY comments that are incorrect and misleading, so most of the unsafe demarcations aren't helpful in achieving UB-free code.

> We can gradually refactor it

Is quite a hell of a statement, when memory management issues are highly nonlocal and need some careful design upfront in order for you to nail it.

Unsafe isn't something that you can gradually clean up. Even one single flawed usage of unsafe (an ill-assumed invariant) can poison the whole program in scary ways, and might require a total refactor of your codebase to fix it.

You do have to inevitably use unsafe because of FFI (Bun uses existing C++ modules like JavascriptCore for most functionality). Optionally also for performance (at least if you want to win Deno on that front)

> clear well-scoped unsafe boundaries

This is not done by blindly porting Zig code 1:1 and calling it a day. You do have to make conscious decisions about code architecture to manage Unsafe code, since you need choose the right invariants for your Safe Rust code to conform inside the module (Note that unsafe pollutes the whole module containing it, not just the code inside the unsafe block!)

... it's a joke. A perfect example of how Plan 9 humor works.