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).
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.
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 ....
The poster did not claim it was a "cure". The way I read it was that if you're gut biome is dysfunctional because you eat too much, that is a factor in the immune response to SARS-CoV-2. That is actually possible. Resetting your gut biome with a 72 hour fast is known to provide significant health benefits. Clearly the poster is not a medical professional and states that fact. But everything stated is reasonable advice. It's certainly not "quack medicine".
Ditto. I have vi going in a term maxed in it's own workspace and just leave it open always so that when I have an idea I just do :r!date to add a timestamp and type in whatever ideas / notes. But I do use separate files for different projects.
Async is superior. I have done processes with locks in shared memory. I have done threads. But I predict Async will slowly start to take over. Processes are not suitable for working on shared data. Threads frequently yield race conditions and deadlocks even for experienced coders. But Async doesn't have any of these issues. So why isn't it more popular? For two reasons:
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 problem is not with digital signatures. The problem is bad ECC certs used to generate digital signatures. So SMB is not affected. Code signed with one of these bad ECC certs is a concern. But considering that people install stuff that's not signed all the time, the primary issue is probably TLS MITM.
Not exactly but I'm not sure it matters. It sounds like if the curve parameters are crafted just-so, they can dodge validation and use anyone's public key and yet still negotiate successfully and decrypt everything. The "gramdma" explaination is basically the green lock next to the URL in your browser doesn't mean spit at this particular moment in time.
I'm starting to like async as in libuv and JS. I don't know what people think of JS but I've done condition variables (Java) and semaphores through shared memory and I actually think async is going to rule long term. Yeah, JS is not procedural. But if you don't fight it it's actually quite elegant. And I'm an old. If I can learn a new way of thinking you can too. And by "don't fight it" I mean no Promises or async / await. Those are just window dressing (and worthless IMO). Just use callbacks. Attach them to an object if you want a single object to pass around like you might with a Promise (that's all a Promise is anyway). You will need to use an arrow function to set "this" though.
The simplified method: Take a guitar and transpose each mode to E. So start with Phrygian since it's natrual key is E. But then transpose Dorian from D down to E. Forget the key. Just learn the modes but from E. THEN, make up chords for each note of each mode. For example, for Mixolydian you can make E, F#m, A, Bm, C#m and D (and a weird G# - there's always a weird chord). Once you memorize the 7 modes, you can deconstruct pretty much any song. Fool around playing chords of a mode and you'll start to hear familiar note patterns. Switch modes (especially for the "weird" chord) and things get very interesting. You don't even have to learn all of the modes. I used 4-5 almost exclusively. Of course it does create a communication problem if you normalize everything to 5 modes and de-emphasize the key.
This post has long since scrolled off the front page but for posterity here is the best part:
"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!
Isn't "AI" pretty much snake oil. IIRC Artificial Intelligence used to mean a computer that could think like a person. But that just is not the case. Even with IBM ads with a computer talking to people saying it's going to fix the network and stop cyber attacks that is just complete nonsense. And it will probably always be nonsense because of course there's no way a computer can think like a person because a computer is not a person. It did not grow up and fall of it's bike and skin it's knee and take a road trip to the rock concert and meet someone and so on. AI is being used as a marketing term to compensate for the fact that sophisticated pattern recognition algorithms and the like are not particularly marketable even if they are useful.
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.