royjacobs

No, that's not needed. There's a K8S plugin for Backstage that can link your deployments to the services in Backstage's service catalog, which is useful. But that's pretty much the only part of Backstage that would "require" Kubernetes.

You are right, this is not going to be trivial and you definitely need buy-in on a management level. Backstage is pretty malleable but the only way to get it to work in an organisation if there is only a single source of truth for things like your software catalog.

If there is a lot of legacy in your org, or if there is not enough buy-in then it will definitely be "yet another" system. There's a lot of functionality to unlock once you have a bunch of data in Backstage, though, so that could help tip the scale. The cloud costs dashboard that helps to show how much every service costs is a good demo :)

One benefit to Backstage's approach is that you don't necessarily need to change your processes and tooling to work with Backstage. It can help, but it's not a strict requirement. Other tooling in the space requires you to buy in to their specific workflows and so on whereas Backstage is a bit more agnostic.

Why is it a "hole"?

The first release to contain bits for Project Loom (the "virtual threads" part of the release notes). That is extremely exciting, since it is designed in a way that mostly allows drop-in replacement of existing threading and thread pool code, without requiring an utterly different programming model like async, coroutines or reactive programming do.

Not the same guy, but if you're interested in the subject https://github.com/xenowing/xenowing is also worth a look.

The purpose of this site is to teach the fundamentals of creating graphics and having them show up on an external display. Driving a VGA signal is extremely straightforward compared to the complexity of HDMI. Generating an HDMI signal is arguably not the main goal of the site, so using VGA makes total sense imo.

I agree KeePass is free, open source and lightweight but calling it easy to use is quite a stretch, especially if you want the same kind of functionality (e.g. autofill in browsers) that other tools provide out of the box.

If you love that kind of thing you'll love the things being produced for https://lovebyte.party/

Thankfully heroes and villains in action movies always drive immaculately restored 70s muscle cars, so for the time being they'll be able to keep using a gear stick.

I used to work for a spin-off of Philips Electronics that did audio and video watermarking and fingerprinting. The audio fingerprinting algorithm is described in this paper[0], it's a very interesting read if you're curious.

[0] http://ismir2002.ismir.net/proceedings/02-FP04-2.pdf

"Any relation to digital sensors is a coincidence."

The colour science of these sensors is designed to emulate the characteristics of film, it's not just raw sensor data coming in. So I wouldn't say it's a coincidence.

Also, in what way does film handle dynamic range better than modern sensors? That's definitely a case of "citation needed", I would argue :)

As an example, if you're writing a shooter then the floor might be a large square that will almost definitely be intersecting the near plane. You absolutely need clipping here.

Indeed. Otherwise you wouldn't be able to render any kind of transparent objects without weird seams.

I think Carmack was mostly talking about regular Visual Studio as his IDE of choice, though. Not VSCode.

The example shown has 14GB of data, which is absolutely tiny, yet it can still rack up $40k in costs per day if used incorrectly (i.e. less than optimal, but not egregiously wrong)? Why would you use this?

Unfortunately good ideas don't count unless you act upon them :)

Can you recommend some channels?

You need to explicitly install these tools, so you can't "accidentally" invoke cargo-buidl from a transitive dependency or anything.

It's not like a tool like npx which will allow you to invoke code in arbitrary packages.

Exactly. Just having a date and some commit hash doesn't tell me anything.

Pickaxe Pete wasn't too shabby, either.

It never ceases to amaze me how much improvements Blender is getting all the time. I've never used it much, simply because I got burned in the past by the (legacy) esoteric UI, but it has increasingly become a joy to get started with and just noodle around with.

There are other cool open source tools of course. Blender could've easily remained another one of those hard to use niche applications, but they've definitely managed to transcend that.

I feel like you are being meta-sarcastic here. It's sarcasms all the way down!

It's not a great look to open a blog post with sarcastic comments referring to (unneeded) controversy, though. Regardless if you were right or wrong.

I'm afraid I only used it for some toy applications and it was mostly fine, but I do concur that if you're going for a 'just a bunch of forms' desktop application you'll find more out-of-the-box features in something like Qt.

If, however, your application mostly consists out of custom GUI elements then JUCE is pretty compelling.

Why would it be terrible? JUCE is meant to write general purpose cross-platform GUIs with.

It has a focus on audio because that's its niche and where it originally came from, but it's fine to use it for general purpose stuff. Is that what you mean?

Is that really the case, though? I thought alternative languages for FPGA development have been a thing for a while now but they haven't really caught on.

The C++ being written in this example also feels like it has to be very carefully considered (and with a bunch of pragmas) so it doesn't feel like C++, it feels like a C++ syntax on top of Verilog or VHDL. Maybe this could still be quite useful, though. I guess simulating might be easier when you can start out with C++ code.

The only XML in this article is about configuring Maven, the build system, though?

I was not talking about runtime vs compile time, I was talking about how you interact with it as an end user.

Ah right, Mono. I keep forgetting that was a thing.

This proposal will pave the way for jextract, though. I would argue this series of JEPs is much closer in spirit to something like Rust's cxx than P/Invoke is.

Has P/Invoke been cross-platform for a decade? Additionally, does it parse C headers to create native type wrappers automatically? Last I checked (a long time ago), P/Invoke required you to annotate manually written prototypes?