Wednesday, November 06, 2024
Tuesday, November 05, 2024
Insanity, LLMs, determination and the future of software development
Insanity Is Doing the Same Thing Over and Over Again and Expecting Different Results
The above quote may or may not be by Albert Einstein. It doesn't really matter.
If you've been around software development for more than about seven minutes, you've probably heard it quoted in some form or another.
It's often used as an argument against blindly repeating yourself, especially when trying to recreate a bug with vague repro steps.
This quote also points to a fundamental difference developers need to consider as the use of LLMs and "AI" become more a part of the software being developed (not just as a tool for developing the code.)
AI (& LLMs in particular) has (have) a level of non-determinism about it (them).
Repeatedly asking the same thing of an LLM shouldn't always produce the same result.
There's a random element that you almost certainly can't control as an input.
Many software developers likely the certainty of software as (in theory) the same inputs always produce the same outputs. The level of certainty and determinism is reassuring.
Businesses like this too. Although it may not always be as clear.
Looking at the opposite situation highlights the impact on businesses.
Business: "How (or why) did this [bad thing] happen?"
Developer: "We can't say for sure."
Business: "How do we stop it from happening again?"
Developer: "We can add handling for this specific case."
Business: "But how do we stop similar, but not identical, things happening?"
Developer: "We can try and update the training for the AI, or add some heuristics that run on the results before they're used (or shown to the user), but we can't guarantee that we'll never get something unexpected."
Fun times ahead...
Monday, November 04, 2024
not writing about the cutting edge
Sunday, November 03, 2024
where did the SOCIAL in social media go?
Wednesday, October 16, 2024
Code signing a VSIX Package with a certificate from DigiC**t
Let's avoid why you might want to do it, but if you need to sign a VSIX package with a certificate from the DigiCert KeyLocker (using their hosted Hardware module service) referenced with a certificate stored in the Windows Certificate Manager, I have important details for you.
Here's the thing.
DigiCert claim that you can use their certificates to sign a .vsix file using SignTool.exe. You can't.
SignTool does not support signing VSIX files.
Previously, the recommended way to sign a VSIX package was with VsixSignTool, but this has now been deprecated.
The current (October 2024) recommended solution is to use the Sign CLI tool instead.
That's all well and good, but there aren't any clear instructions (anywhere!) that explain how to do this with a code signing certificate hosted in a DigiCert KeyLocker.
If you're trying to do this, I'd recommend not contacting DigiCert support as they're likely to tell you something like:
It seems our documentation is correct, it is supported, but does not specify the "how". As that would be listed as a third party custom configuration, which is something that is not supported at this time.
That's not at all helpful.
They may also point you to this (devblogs) blog post, but that still doesn't contain a complete working example for this scenario.
Here's what I recommend (based on what I've managed to get working and now use--don't ask how long it took to get working as it's very depressing.):
- Set up your machine following DigiCert's instructions until you get to a point where you can successfully sign a .dll file with smctl.exe.
- Install the SIGN tool.
- Install KeyStore Explorer.
- Use KeyStore Explorer to get the SHA256 version of the fingerprint for the certificate you wish to use. (and remove the colons between values)
- Sign the VSIX with a command like this:
I hope this helps someone.
Yes, using something like AzureKeyVault is probably preferable. If you have detailed, up-to-date instructions on how to set this up, please share them.