14 karma · joined September 24, 2019
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.
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 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?
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.
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 ....
1) it completely breaks the functional programming model that we all learned as toddlers (instead of call A and then, after that's done, call B, Async is call A which just installs B as a callback, returns immediately and then an "event loop" calls B). Note that promises and tasks and futures are just "syntactic sugar". Personally I'm not a fan. I don't use any of that. I just use callbacks.
2) Even though Async it's great for concurrency, it's not great for parallelism. Everything runs with one thread. So if you want parallel processing you need workers.
But I would argue that issue 1 can be overcome. In fact, I find Async to be quite elegant. I think in the long term people are going to realize that maybe we've had it backwards all along.
Issue 2 is actually not that big of a deal for most things. It's actually somewhat unusual that you need to have some CPU intensive operation running in the background. Maybe image processing, data modelling, etc. But most blocking operations are just I/O operations which are not using CPU that much. If I needed to write some kind of network server, I would look at using libuv as a portable runtime.
"The fact is that good system design takes time; it is the sort of thing that requires hard solo thinking along with long discussions with other engineers. There are days when no real progress seems to be made, and other days when the only progress is to realize that what you thought was progress over the previous few days or weeks was in fact a wrong turn that won’t really work. Such a realization is progress. In fact, such a realization may be the most important kind of progress, as it can save huge problems later in the project. But to a manager it may not seem to be moving forward."
I recently came to this exact realization. So when I saw this post I had to see if it was in there. And it is!
More specifically, it's not just something at the end appearing at the beginning causing skipping like others have pointed out. The skipping can happen in the middle. Consider the two sequences A B B C and B C A. Your algo will match the first Bs and then the Cs and skip the common B C together.
Even if you could somehow make it work, it would be O(N) but note that with all of the split() and map() and array indexing, it starts to be more like O(N+NX) where X is that potentially non-insignificant overhead.
Don't let me pooh-pooh you from trying but if you do give-in and use the Myers' algo, here's my C diff implementation:
http://www.ioplex.com/~miallen/libmba/dl/src/diff.c
This is actually pretty compact as diff implementations go and would probably be a reference for implementing diff in JS.