Both points here are appreciated. One that a README file as a "placeholder" for a directory gives the opportunity to describe why said empty directory exists. I would be slightly concerned though if my build process picked up this file during packaging. But that's probably a minor concern and your point stands.
Additionally, the AI comment is ironic as well. It's like we're finally writing good documentation for the sake of agents, in a way that we should have been writing all along for other sentient consumers. It's funny to see documentation now as basically the horse instead of the cart.
I agree with you. Empty .gitignore would be a "smell" to me. Whereas .gitkeep tells me exactly what purpose it serves. I like the semantic difference here that you describe. I don't like when multiple .gitignore files are littered throughout the codebase.
I'm not sure that governments actually create them, not prolifically at least. There's been some state actor influence over the years, for sure.
However, exploits that are known (only) by a state actor would most definitely be a closely guarded secret. It's only convenient for a state to release information about an exploit when either it's been made public or it has more consequences for not releasing.
So yes, exactly what you said. It's easier to find the exploits than to create them yourself. By extrapolation, you would have to assume that each state maintains its set of secret exploits, possibly never getting to use them for fear of the other side knowing of their existence. Cat & Mouse, Spy vs Spy for sure.
I don't want to be called "gorgeous", but I admit that some of my "love language" is positive affirmations. As a man, I want to know that I am making a positive impact on my family, my wife, my community, my work. I crave that strong positive feedback, just as much or more as anyone.
So yes, I think it is a bit sexist or at minimum gender typing. And I don't think it's necessarily a "lie" for you to overstate your feelings. You might have matured in your approach, but I believe that everyone appreciates (to some variable measurement) positive affirmation from their partners. And that your lie was recognizing your partners needs for inputs, to help them in their self-image, and to assure them in their self-doubts. These are not lies.
My problem isn't with positive affirmation, which I will happily give. Complimenting others, but something so excessively superlative that it feels like manipulation.
For example if I told you 'good thinking', you would probably think I am giving a token of appreciation to you. If I told you 'wow, you are absolutely brillant!', you'd probably think I'm mocking you or trying to manipulate you into doing something.
I'm so grateful for flat LCD screens. Man, all those CRT boxes. Yikes.
The rest of this video, it doesn't look like the world has changed all that much since 1995. Computing just kind of looks the same. I guess minus the lack of phones in everyone's hands.
Well, I mean, the first part is a song by Don McLean called American Pie. You might know that, unsure that everyone will pick it out though.
One of the most famous play choices at karaoke bars these days too. I think because the song is a long story, of sorts? But it's a terribly long song and I will leave to take a smoke break anytime it gets chosen. You're going to be there for a good 10 minutes before it concludes.
So maybe the AI prompt was something like, "take CVE-2026-24061 and compose a song lyric in the style of American Pie by Don Mclean". I wonder if you would get similar results with that prompt.
The rest of it seems to be substantially edited by an LLM too, or at least it's composed much like LLM outputs often are these days: “not a gradual decline, not scanner attrition, not a data pipeline problem, but a step function.”
"Not X, not Y, not Z" is a common LLM tic, and there's a few more like it in there.
I mean, that's fair. I guess I just wanted to put my old man hat on. The song is a tribute to an era of lost innocence. Which I think is quite apropos to the current situation surrounding telnet. Vestiges of the days of the early internet continue to disappear, almost like an endangered species. Old/obsolete protocols, like telnet, are pined for by old guys like me.
I was at a bar a few months back, drinking some brewskis with my broskis, and there was a guy with a guitar playing some songs. He started singing (bye bye miss) American Pie. Somewhere around the 4th verse he got stuck in a loop and sang that verse 3 or 4 times before he gave up.
How do you automate, for example, "HTTPS over websocket with OAuth", without providing some kind of hard-coded, static or otherwise persistent authentication credentials to the calling system in some form (either certificate based auth, OAuth credentials, etc.)?
The problem with IoT and embedded secrets isn't really a solved problem, from what I can tell. I'm not sure that OAuth exactly solves the problem here. Though all your comments about SSH (especially host verification) holds true.
Just honestly trying to understand the possible solution space to the IoT problem and automated (non-human) authorization.
Honest question. Do you recommend a "devcontainer" for this? Like a Docker image that maybe has both postgres and your development environment preinstalled inside? Or do you generally like to use and reference an external docker container instance (with postgres installed) and connect to it from your devcontainer instance?
So if I'm building Python application with Prometheus/RabbitMQ/PostGres that's used as part of my application, My docker compose has network, those 3 services + Python Dev Container and I just reference the hostname of the service in my Python application config (ENV VARS).
This is a pragmatic answer. While yes, regex is not proven to be the Most Correct Solution for a generalized parse, when you are sitting down with some data in front of you and you can grab the needed bits with a regex group, why not exactly use this. It might be part of a bigger parsing strategy, sure. But if it gets the job on, that means you can move on to the next thing.
Your point is valid though. It would be much preferable to include build/ in your root .gitignore so that the directory is never tracked.
reply