Reading these dot-related comments reminded me that I once made one here about how I was able to leverage this possibly asynchronous dot-handling at gmail. Because the story is a bittersweet sentimental one for me I had to go back and read it now, and though I am sitting here with bad allergies streaming down my face, it also felt really nice to remember that.

I know this is a bit of a sideways comment, and I apologize for that but it isn't often I am overcome with emotion on HN, or on the topic of email addressing, and well, I appreciated the opportunity to re-read it now. Thanks.

You might find my gmail dots story interesting too. It's a little long, but the dot-character portion begins about a third of the way down in my comment:

https://news.ycombinator.com/item?id=46539424#46541149

Cheers!

The venue and publication are a good fit for the paper and serve as useful signals for the temperament of the paper and the treatment throughout the development of the model. It also says something about the reviewers acuity and elite selection criteria, which are to be celebrated for what they are.

The conference proceedings are also available in print from Lulu at https://www.lulu.com/search?sortBy=PUBLICATION_DATE_DESC&pag... Just FYI.

As my paper's abstract makes clear, the model is not offered as a predictive instrument in the strict scientific sense. It is instead a formalized account of a familiar practitioner truth: software delivery is not shaped only by pipelines, tooling, deployment frequency, or architectural complexity; it is also shaped by technical debt, morale, urgency campaigns, competence mismatch, and executive volatility.

The ethos of GUM does not stem from a belief that DevOps metrics are useless. Rather, they are useful enough to make omissions conspicuous. If we can assign symbols to deployment frequency and change failure rate, we may eventually have to admit that organizations themselves also perturb the system. Recent literature has done much of the work of formalizing the example proxies given in GUM 1.0, which allows us to construct a new model that may satisfy the critics who claimed GUM 1.0 required "measuring the immeasurable."

While researching for GUM 2.0, we were surprised by how rapidly the recent literature appears to be moving into territory adjacent to that of the GUM. One paper formalizes delivery speed as a function of automation and CI/CD maturity; another models developer-experience variables such as cognitive load and technical frustration as causal contributors to release-cycle duration, which looks quite a lot like the GUM term M (Developer Morale Multiplier). A third attempts to quantify technical debt as a compound-interest problem with remediation ROI. It is, of course, an honor to see how much impact the GUM has had, even if it has not yet been cited in any papers. A more thorough survey of these papers from recent literature can be found at the GUM's primary site at https://github.com/scottvr/GUM_of_Devops/blob/main/sigbovik2...

We are currently working to address these developments in GUM v2.0. As stated in the original "Grand Unified Model of DevOps", when the real world begins to collide with a model, *it is time to introduce more formalism.*

Comments URL: https://news.ycombinator.com/item?id=48352245

Points: 3

# Comments: 2

I wish I had written that.

Also interesting that while the big vendors are following this trend and are now trying to take a lead in it, they still suggest things like "but use a JSON schema" (the linked article does a bit of the same - acknowledging that incremental learning via `--help` is useful AND can be token-conserving (exception being that if they already "know" the correct pattern, they wouldn't need to use tokens to learn it, so there is a potential trade-off), they are also suggesting that LLMs would prefer to receive argument knowledge in json rather than in plain language, even though the entire point of an LLM is for understand and create plain language. Seemed dubious to me, and a part of me wondered if that advice may be nonsense motivated by desire to sell more token use. I'm only partially kidding and I'm still dubious of the efficacy.

* Here's a TL;DR for anyone who wants to skip the rest of this long message: I ran an LLM CLI eval in the form of a constructed CTF. Results and methodology are in the two links in the section linked: https://github.com/scottvr/jelp?tab=readme-ov-file#what-else

Anyhow... I had been experimenting with the idea of having --help output json when used by a machine, and came up with a simple module that exposes `--help` content as json, simply by adding a `--jelp` argument to any tool that already uses argparse.

In the process, I started testing, to see if all this extra machine-readable content actually improved performance, what it did to token use, etc. While I was building out test, trying to settle on legitimate and fair ways to come to valid conclusions, I learned of the OpenCLI schema draft, so I altered my `jelp` output to fit that schema, and set about documenting the things I found lacking from the schema draft, meanwhile settling to include these arg-related items as metadata in the output.

I'll get to the point. I just finished cleaning the output up enough to put it in a public repo, because my intent is to share my findings with the OpemCLI folks, in hopes that they'll consider the gaps in their schema compared to what's commonly in use, but at the same time, what came as a secondary thought in service of this little tool I called "jelp", is a benchmarking harness (and the first publishable results from it), the to me, are quite interesting and I would be happy if others found it to be and added to the existing test results with additional runs, models, or ideas for the harness, or criticism about the validity of the method, etc.

The evaluation harness uses constructed CLI fixtures arranged as little CLI CTF's, where the LLMs demonstrate their ability to use an unknown CLI be capturing a "flag" that they'll need to discover by using the usage help, and a trail of learned arguments.

My findings at first confirmed my intuitions, which was disappointing but unsurprising. When testing with GPT-4.1-mini, no manner of forcing them to receive info about the CLI via json was more effective than just letting them use the human-friendly plain English output of --help, and in all cases the JSON versions burned more tokens. I was able to elicit better performance by some measurements from 5.1-mini, but again the tradeoff was higher token burn.

I'll link straight to the part of the README that shows one table of results, and contains links to the LLM CLI CTF part of the repo, as well as the generated report after the phase-1 runs; all the code to reproduce or run your own variation is there (as well as the code for the jelp module, if there is any interest, but it's the CLI CTF eval that I expect is more interesting to most.)

https://github.com/scottvr/jelp?tab=readme-ov-file#what-else

https://web.archive.org/web/19991109163128/http://www.dfw.ne...

Using named pipes in this manner also enabled a hackish method to create server-side dynamic web content by symlinking index.html to a file created in this manner, which was a secondary motivator, which seems kinda quaint and funny now, but at that time, it wasn't very long after just having finally decommed our gopher server, so fingerd was still a thing, Apache was fairly new, and I may still have been trying to convince management that the right move was not from ncsa httpd to Netscape Enteprise Server, but to Apache+mod_ssl. RSA patent licensing may still have been a thing too. Stronghold vaguely comes to mind, but I digress.

Yeah, programs that do stuff based on filename, like busybox. Oh, and this long forgotten artifact this article just reminded me of that I managed to find in the Wayback Machine, a tool to mknod a named pipe on a SunOS 4.1.4 machine, to get server-side dynamic content when remotely accessing a daemon that was supposed to return content from a single static file. Ah, memories.

https://gist.github.com/scottvr/f968b65bedf7a4635a4cdd643628...

It is ludicrously-escalating grotesque sci-fi (intended for sending over SMS), so you can safely skip it if that's not your cup of tea.

I have been solely using an old X86 Darwin MacBook Air for this, so that's the extent of the platform(s) tested. (Writing this has caused me to realize I might want to document the process of installing the FUSE driver on a mac, but I do link to the MacFUSE webpage, which is probably more broadly useful than my experience on this dated laptop.)

Anyway, I actually went searching before posting because it hadn't occurred to me that this might have already been done somewhere else (yeah, one might think searching for an existing solution would be a first thing...) and was happy to see that it doesn't seem to have been exactly put out there before, while also being a bit surprised to see that so many spiritually-related FUSE implementatations have been created since last I had occasion to do anything with FUSE. It might be the case that if I have done this correctly, very-specific niche FUSE implementations will be unneeded, as my hope is that apifusefs is capable of handling any swagger-type, OpenAPI-spec API.

(Eventually, anyway. For example, there exists a massive openapi.json for the GitHub API, but due to the way the root endpoint refers to other endpoints, and each has its own context and auth-requirements, this initial release of apifusefs isn't magic for api.github.com/ even with the spec file, and I had to mount specific endpoints by their URL given in the response to "GET /", to varying degrees of success or failure, which is what caused me to add the --json-file mode,so I could just redirect the output of a curl request to a file and test with that.)

That said, it does now support a variety of ways to pass authentication tokens, so my hope is that if anyone here has an API to try it out against, that it will work for you without hassle.

Requires libFUSE (MacOS/Linux) and Python. It was made because I am a CLI kind of guy, and I live in a terminal so being able to fallback on muscle-memory shell instincts (for loops, piping commands and I/O, etc) without having to do a bunch of curling, or browsering, postman, etc.

It occurs to me that with all the hype lately about AI agent tool use, that it could be useful for this purpose as well, since the Agent would not need any special skill for it; the data just becomes navigable and readable as with any file in a directory tree.

I'd be interesting in hearing if you find this useful, dumb, broken, lacking an obvious feature, or anything else you might have to say about it.

Comments URL: https://news.ycombinator.com/item?id=47256567

Points: 1

# Comments: 1

In the post, as I tried to capture in the title submitted, I outline my journey of exploration, when I became determined to make GitHub-Flavored Markdown display my text, with color, style and alignment of my choosing, which as I discovered after setting out to do so, the inability to do such a thing outside of fenced blocks with pre-defined syntax highlighting is a well-known condition, which is met with "works as intended" response because, well, GitHub doesn't want their repos looking like MySpace or Geocities or presenting security risk exposure by allowing arbitrary html/CSS styling. Sure, I should have used GitHub Pages to build a page from my Markdown using Jekyll, which is a supported way to control the styling of your own documents in your repo, but where's the fun in that?

The linked post documents the workaround I arrived at, which became an output target format that nobody has ever asked for from my ASCII line-Art diagramming tool. I thought some here might appreciate the documentation of "wasting my time so you don't have to" on a technical solution for a problem I probably just shouldn't have cared about and moved on.

Comments URL: https://news.ycombinator.com/item?id=47203584

Points: 4

# Comments: 1

I was going to follow this with something like "except the role of analyzing the emotional response is reversed", and then I wanted to expound with an "ooh but.. wait, there's another metaphor here since ..." but thought I've already potentially approached "spoiler alert" territory so I'll just stop there. Those who know the reference I am replying to will know; those who don't, well, don't google any of this or its parent cuz spoiler alert

As such, I wish you the best of luck with this project - earnestly so - because if, as I suggest, it is inevitable... we want such a system to be as good as possible.

An aside: another inevitable use case just came to mind - that of the cheap, shoddily implemented and poorly tested (along with the insecure, surveillance-adjacent products that will proliferate) kid's toys with embedded AI and the sardonically-humorous privacy mishaps and unintended actions from such low-quality implementation toys being sold (see: the current LLM-enabled kids toys currently popping up routinely at retailers.) ha! Sorry I keep taking your cool demo to dystopian extremes. :)

Oh, one more thing... Upon re-reading my previous comment, I recognize that the description of my visceral reaction as on of being being "repulsed by the thought" could literally be read as me calling your system "repulsive", which was not my intent. I think your tech is cool, and was just trying to convey two conflicting feelings that occurred within me when thinking about the future commercial use cases. I hope your systems works great so that if it does find market fit with such use cases, that, well... if it's inevitable - as the last few years of "LLMs everywhere!" has forced us all to adapt (accept or reject it, it still requires new effort) - we should hope for a good and working system, so I hope you succeed in making one.

Lastly, to your self-driving/potholes analogy... I do think that that fits more in line with my "objective CV classification" category; I think a closer fit to what you're building would be "self-driving car having to handle the Trolley Car Problem", with the nuances of human value judgements etc; does the car swerve into two adults vs one child? And so on. Pothole classification is more objective while driving into it, swerving to avoid it, classifying pedestrians and choosing one to possibly collide with, etc are subjective and more complicated (as is your system and the functions it can perform.)

Best of luck!

One part of me has a tendency to think "good, take some subjectivity away from a human with poor social skills", but another part of me is repulsed by the concept because we see how otherwise capable humans will defer to "expertise" of an LLM due to a notion of perceived "expertise" in the machine, or laziness (see recent kerfuffles in the legal field over hallucinated citations, etc.)

Objective classification in CV is one thing, but subjective identification (psychology, pseudoscientific forensic sociology, etc) via a multi-modal model triggers a sort of danger warning in me as initial reaction.

Neat work, though, from a technical standpoint.

Some may find this interesting https://www.fcc.gov/calea

One other thing that might be worth a mention is the concept of the OS' resolver and "suffix search order", with an example of connecting (https, ping, ssh, whatever protocol) to a host using just the hostname, and the aforementioned mechanism that (probably) allows this to connect to the FQDN you want. (Also, now that I type that, do you mention "FQDN" at all? If not, maybe should.)

On that note one final thought that occurs to me is the error/confound that may occur if a hostname is entered and is not resolved, but does resolve with one of the domain suffixes attached on a retry (particularly can be confusing with a typo coupled with a wildcard A record in a domain, for example.) I recognize that the lines that look like DNS records are not explicitly stated to be in a format for any particular dns server software, and even if they were, they're snippets without larger context so we don't know what the $ORIGIN for the zone might be, an adjacent concept you might want to explore, even if just for your own edification is that of the effect of a terminating "." at the end of a hostname, either at resolution or configuration time.

Just offering feedback that might help you add to the article.

There's an example of a fairly complicated graph of chess grandmaster PGM taken from a matplotlib example from the NetworkX documentation website, among some more trivial output examples in the README at https://github.com/scottvr/phart/blob/main/README.md#example...

(You will need to expand the examples by tapping/clicking on the rightward-facing triangle under "Examples", so that it rotates to downward facing and the hidden content section is displayed)