bodeadly

ChatGPT and Cursor both failed hard. Even after walking them backwards through the flaws in their answers they just refused to see it. When I stated flat out what the answer was ChatGPT agreed in the end. Cursor did not. Cursors initial reply was -200g. Then I challenged "But I did not tare it after adding the almonds." and again it failed with: "That doesn't change the final reading: it still displays -200g.". When I walked it back further with "If I put the container on the food scale, tare it and remove the container, what does the scale read?" it correctly replied "negative the weight of the empty container" but ... when I asked "So does this impact the agents answer to my original question?" it replied "No, it doesn't change the answer—the scale still reads -200g". LLMs are NOT good at even basic numeric accounting.

I'm not sure LLMs will be good at doing taxes any time soon primarily because they're very bad at even simple math unless it's explained in words like in proofs. A good illustration of this is asking an LLM something like this: "If I put a container on a food scale, tare it, add 100g of peanuts, tare it, weigh 100g of almonds and then remove the container from the scale, what does the scale read?" LLMs completely puke all over themselves on this one. They do not account for not taring after the almonds and they do not see the weight of the container needs to be subtracted. The correct answer is minus (100g + container weight). Although this particular question also exploits another LLM weakness which is physical world concepts. LLM are just guessing. For an LLM to do taxes well, it would need to be trained on many scenarios and it would need a math service that it can use as a support service.

Yes. It's because you are asking it to generate an image of a pelican riding a bicycle. If someone asked you to draw a pelican riding a bycycle, would you interpret that to mean using 3d photorealism? LLMs follow conventions. The convention for an animal riding a bike is to create a childish 2d line drawing.

Like anything in coding, it depends. LLMs are good at following conventions. If what you're doing has been done a 1000 times before and there is a good bias, it will produce good results. This is why LLMs are so good at the leafy parts and even the branches the leaves are connected to. But there's always something unconventional about a codebase. If there weren't, it wouldn't be worth writing.

Tip: LLMs are very good at following conventions (this is actually what is happening when it writes code). If you create a .md file with a list of entries of the following structure: # <identifier> <description block> <blank space> # <identifier> ... where an <identifier> is a stable and concise sequence of tokens that identifies some "thing" and seed it with 5 entries describing abstract stuff, the LLM will latch on and reference this. I call this a PCL (Project Concept List). I just tell it: > consume tmp/pcl-init.md pcl.md The pcl-init.md describes what PCL is and pcl.md is the actual list. I have pcl.md file for each independent component in the code (logging, http, auth, etc). This works very very well. The LLM seems to "know" what you're talking about. You can ask questions and give instructions like "add a PCL entry about this". It will ask if should add a PCL entry about xyz. If the description block tends to be high information-to-token ratio, it will follow that convention (which is a very good convention BTW).

However, there is a caveat. LLMs resist ambiguity about authority. So the "PCL" or whatever you want to call it, needs to be the ONE authoritative place for everything. If you have the same stuff in 3 different files, it won't work nearly as well.

Bonus Tip: I find long prompt input with example code fragments and thoughtful descriptions work best at getting an LLM to produce good output. But there will always be holes (resource leaks, vulnerabilities, concurrency flaws, etc). So then I update my original prompt input (keep it in a separate file PROMPT.txt as a scratch pad) to add context about those things maybe asking questions along the way to figure out how to fix the holes. Then I /rewind back to the prompt and re-enter the updated prompt. This feedback loop advances the conversation without expending tokens.

Ultimately Kerberos is used to authenticated basically everything in a Windows on-prem environment and in a way that is largely transparent to the user. Silent SSO is a very nice feature. Even if you're doing OIDC or SAML, those protocols do not define what is actually performing authentication at the IdP which, again, ultimately ends up being Kerberos if you're people are on-prem. So whatever your feelings are about Kerberos as a protocol, it doesn't matter if that's what Windows uses. And again, it cannot be obsoleted by other protocols. Even if you're using a newer fido thing like passkeys or client certs or whatever, ultimately the device has to be authenticated to get that passkey or cert or whatever it is installed into the authenticator app of the device. So Kerberos is king on prem. MIT Kerberos on Linux is not really compatible with Windows Kerberos in ways that cause problems that are not solved by re-writing Kerberos in another language. More important issues have to do with sharing credentials and getting trust info and other such things.

I use the bemis bidet adapter. It's $50 US on amzn and requires no power (splices into the feed). Only wish the knob would spring back to the off position. Was going to give it to my parent with dementia but because it does not auto-off, I ended up using it myself. Great item. There are many other similar ones but I can only speak to the bemis one.

Writing code is easy. Knowing /what/ to write is hard. I know how to write English. But that doesn't mean I can write a book (that someone would want to read). AI can write code. But it still has to be told what to write.

I'm not a fan of XML either with the exception of one purpose which is document processing using XSLT. XSLT is THE correct way to generate documents. Markdown is extremely limited by comparison.

And I'm not suggesting that there would be no documentation in the code. Javadoc is written for consumers of the code being document. That is incorrect. The comments should be optimized for the developers of the code itself. And it should not explain what the code does if you can just read the code itself.

So again, IMO, javadoc is a mistake. It mixes up two largely different things.

Also, when you downvote someone, it's not supposed to be because you don't agree with their view. You downvote someone when they say something that does not contribute to the discussion. But do what you will ...

I would argue that API doc text should not be inlined with code at all. It's just noise. It should be in a separate XML file with a minimal schema. Then building the javadoc is just running xsltproc with a javadoc.xslt. Then you also have the option to use your own xslt file to generate pages that integrate with your com / org site (like learn.microsoft.com).

Dread.

I run all of my Windows Server / 10 / 11 client VMs on ESXi for testing my Java software product.

I'm getting the impression that proxmox is the only real alternative for Windows guests?

I do need to get packet captures from the host so maybe Linux is better than something like Hyper-V?

I have a crazy theory: Zillow is directly responsible for the housing shortage and high home prices. Zillow inspires people to move. More moving means houses get fixed up which increases home values. Browsing through homes on Zillow might start out as something to do when your bored but that can easily lead to "what if" thinking. Before Zillow they wouldn't even be thinking about moving.

The blog article doesn't actually say the IAKERB impl will proxy to KDCs. Strangely it is entirely specific to Windows 11 and by extension Windows clients. There is no mention of Windows Server. So it's not crystal clear to me that the implementation will be able to authenticate domain accounts. Maybe it will only authenticate against the "LocalKDC" on top of the local SAM just to work around the issue of being able to log into a machine without line-of-site to a KDC (or NTLM or VM console) and nothing more.

This is not accurate.

NTLM provides signing and sealing using a session key. It is the responsibility of the protocol using NTLM for auth to use that key to sign or seal. The problem is that this feature is frequently turned off.

So it's actually not accurate to say "NTLM is vulnerable to relay attacks". If someone turns off signing in SMB to improve performance, that is not a problem with NTLM, that is a problem with the operator turning off signing. If a door has a lock but it's left unlocked, is that a problem with the security of the door?

NTLM also calculates a MIC over all of the NTLMSSP tokens which provides integrity protection independent of the protocol using NTLM. That MIC includes the target SPN so even if signing is turned off, it cannot be hacked.

Regarding hashes, there are two types of NTLM hashes. There are the password equivalent hashes which are only accessible through hacking system memory of a compromised machine that has access to them. It suffices to say, this is not the path of least resistance for an attacker. This is also known as "pass the hash".

Then you have what are called NetNTLMv2 hashes within the NTLMSSP tokens exchanged during authentication. These are muxed from the password and challenge using MD4 and MD5 but also RC4 if key exchange is used (session key mentioned above). This is not trivial to break. It could easily take a room full of GPUs months and maybe never depending on the generator and complexity of the password.

The problem with NTLM is not so much with the NTLM protocol itself but with the various implementations that either don't implement the necessary security features or they simply get turned off. Last I checked Windows Server domain members do not require clients to negotiate signing by default. If an acceptor required an SPN and a MIC, that would stop a relay attack even if signing wasn't used (because they would not be able to forge the MIC without the password and the MIC factors in the SPN).

Another issue is that the security community needs to find issues to justify their existence. NTLM being oldest and relatively weak crytographically naturally draws a lot of critisizm. But the facts are obscured and hyperbolized regularly. People largely regurgitate what they hear without really knowing what they're talking about. They need to to make it at least sound like they know what they're talking about. The only way anyone REALLY knows how this stuff works is to studying the documentation ([MS-NLMP].pdf), looking at captures and step through computations in code.

Yeah, I don't get it either.

On a related note, folks who are thinking we'll just use Debian or SUSE or whatever other distro, don't understand what RH does. RH is one of the principal contributors to core Linux components used by all distros. Who makes some 10GbE driver work really well? RedHat. And that driver makes it's way back into the kernel sources used by all distros. So I think there's a lack of understanding of the dynamic here.

The allure of RHEL clones is that it's all been checked over by organized engineers who's job security depends on the quality of their work. I would much prefer not to rely on a couple of free-timers producing a result equivalent to what RH does.

And yet there is a huge demand from folks that simply cannot pay what RH wants. So my guess is that something new is going to come out of all of this ....