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.
> 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.
When it works. And when it doesn't work (which is most of the time if you're outside of corporate LAN) you simply can't debug what's happening.
> MIT Kerberos on Linux is not really compatible with Windows Kerberos
It actually is! Long, long time ago I managed to join Windows into a pure Kerberos domain. Everything worked, including things like GSSAPI authentication in Putty or MySQL. It involved some `ksetup.exe` incantations, I think this guide might be still relevant: https://docs.oracle.com/cd/E19316-01/820-3746/gisqf/index.ht...
Of course, there was no group synchronization (because no AD).
That was about 20 years ago. Back then, I was working on helping companies migrate to Linux, and I toyed with an idea of having a background service to periodically sync groups from the Linux SMB server with the local users.
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 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).
No thank you. As someone who has to read code in addition to writing it, it's great to have the doc comments right there, so I don't have to open and search through another document.
There's also the issue of keeping things up to date: it's much more likely that a programmer is going to keep docs up to date if the doc is right there along with the code than if it's in a separate file.
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 ...
Hard disagree. I often read header files directly for documentation and think it’s pretty great. Makes it easy to delve into the source if needed and I dont have to leave my terminal/nvim
You would be wrong. The closer documentation is to the code, the more likely it is to be seen, and to be updated. Reading and writing the docs are more common operations than “writing a new doc transformation tool” by at least 4 or 5 orders of magnitude; the ease of writing new doc transformation tools should not be the determining factor in a design.
I tend to use those VE, virtual environment to make distinguish between containers, VMs and lightweight full OS based containers, since the days of using OpenVZ - may be i'll like that naming too.
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 US has not built enough homes to meet demand for over 30 years which is by far the biggest factor in high housing prices. Zillow is not causing people to move more, the number of Americans moving each year is reaching record lows. High housing prices mixed with high interest rates is causing people to stay put because the cost of buying another home is much more costly. You have to go from your old low-interest mortgage to a high-interest one and high housing prices means realtor fees are also sky-high.
Agree that Zillow and similar make it much easier and top of mind. Home flipper shows on HGTV are also part of the equation since it looks very simple and like guaranteed profit.
"You put $40,000 into your kitchen and bathroom remodel, so that will increase the value $100,000".
There's definitely value for opportunity cost, but oh boy do some of those shows exaggerate it to the point of absurdity. Especially when it's a builder-grade remodel.
Interesting idea, I would argue the opposite on the basis that easier, more frequent transactions in a market improves price discovery and keeps the housing price closer to the "true" price based on supply and demand.
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.
> The blog article doesn't actually say the IAKERB impl will proxy to KDCs.
But that's all IAKERB does. There's two use cases here: proxying to the local, SAM-backed KDC for workgroup mode authen., and proxying to domain controller KDCs for RDP and RAS and what not where the [K]DCs are not reachable directly by the client.
(There's a third use case that they don't currently seem to intend to support, which is when you try to authenticate to a Windows system by IP instead of by name. In that case they could extend IAKERB to use the Microsoft user-to-user Kerberos protocol to discover the server's name.)
> Strangely it is entirely specific to Windows 11 and by extension Windows clients. There is no mention of Windows Server.
Steve Syfuhs addressed this on twitter: there's only one Windows now, so there's no need to mention "Windows Server" because "Windows Server" == Windows.
