I would also point out that users of roffume can consider roff an "implementation detail" and ignore it entirely. The main benefit of roffume is the creation of "per-application, self-contained folders" containing all inputs (markdown), outputs (PDFs), and commands.
Good point about style; I was thinking more about \f[I] than .I. So yeah, I see that if you have every semantic thing on its own line, diffing and maybe readability is better.
Makes sense, thanks for the reply. You have a point about "diff by line", and I might have not gone all in on serious roff to land on all the benefits.
Another thing I see as an example of markdown being slightly more readable: Unlike roff, not needing to escape some typographical marks (like - to get a hyphen). And the better syntax highlighting support for stuff like bold, italics, and so on in Markdown.
Good question. I had an unreleased version of this project running on groff only for quite some time.
After using it for 25 or so applications, I got the feeling that having markdown as the "source of truth" was slightly easier for reading, checking, and diffing different versions. I've been using it with Markdown as a base and I'm happy with the results.
Basically, I found Groff's syntax slightly "heavier" than Markdown for everyday visual use.
Having said that, I know that a lot of the visual clutter issues can be fixed on the groff side. If you actually have a groff resume format that is very readable for you, I would like to take a look and maybe reevaluate if i'm doing groff the right way.
I guess the argument is: If you want human-readable archives, you can then pick txtar. But mongotar basically adds some of the tar features which were missing from txtar
Hey, absolute props for replying to my code by making a counter-code of your own!
I don't have the time to look into this right now, but wanted to say that this is the best I could hope of posting my random projects here: Having someone else tell you what they would do instead.
And for context, this was a weekend experiment. I wanted to try building "agentic stuff," and exploring the not-so-promising intersection of information theory, LLMs, and code quality.
So how does it connect to any LLM without using their API?
Well, the typical use would be by local Agent subscription. But in theory any LLM could work, so long as it's made to follow the filesystem protocol that faaah expects.
There's a video in the repo with an example of how it works, plus a diagram.
Do you think rather than AI was used for most of the code? I don't think it was.
If what you're saying is that "vibe-coded" applies when "some AI was used", and that it's a bad thing, that's a valid opinion that I might agree with in some contexts (like an ethical one).
It's not, but some AI was used for the code. I think vibe coding it would have produced a very different (and larger) code base. What makes you think it's vibe coded?
Yes. The idea is that you can have any tool on one side (which expects an OpenAI-like LLM API, which is a bit of a de facto standard), and any LLM on the other side (which can be an agent subscription).
I used this, for example, to test GraphRAG locally (which is designed to make a lot of LLM API calls) by piping it to an agent subscription I already had (and not needing to buy expensive API tokens for the low volume I needed).
Well, the main reason why I post my projects is for people to tell me what alternatives I'm missing, so thanks for that.
I'm actually not that familiar with Kilo, but I believe it's an agent/IDE-extension, and that you can use different providers for it, including coding agents (I think this is what you were referring to.)
So basically my use case is more niche. I just had an external tool (Graphrag) that only worked with an LLM API, and I had just an agent subscription, so i built an agnostic protocol via the filesystem to make them work together.
It's agnostic because you can have any tool on one side (which expects an OpenAI-like LLM API), and any LLM on the other side (which can be an agent subscription).
Nothing in Kilo would have allowed me to get Graphrag working, I think.
My initial use case was testing graphrag locally, which might become relevant at work later on, so I generalized the thing I did to get it working through an agent subscription. Actually that usage is public too: https://github.com/sebastiancarlos/graphrag-faaah
Thanks for the feedback. I'm the author of the medium blog post too.
If you have any tips on where to find a better free voice, I'm all ears. I haven't tried chatterbox yet, that one might do it.
It could also be that the "direct blog post to video" format doesn't cut it. But I'm still experimenting with ways to generate effective multimedia out of my content.
The article literally starts with "In 2026, the job market is tough. AI plunged us all into economic despair" (itself exaggerated, and a play on the typical "AI doomer" clickbait articles saying what we all know more dramatically, which is another can of worms).
It shouldn’t be a sentence for poverty.
Agreed. And in the article it isn't. He does get a job at the end.
But yeah, I can see how your reading of the article is valid. I'll sleep on it and see if I can do something about it.
Typst is cool. I probably would have used it myself if it were mature enough by the time I started with this project.
I would also point out that users of
roffumecan considerroffan "implementation detail" and ignore it entirely. The main benefit ofroffumeis the creation of "per-application, self-contained folders" containing all inputs (markdown), outputs (PDFs), and commands.Good point about style; I was thinking more about
\f[I]than.I. So yeah, I see that if you have every semantic thing on its own line, diffing and maybe readability is better.Makes sense, thanks for the reply. You have a point about "diff by line", and I might have not gone all in on serious roff to land on all the benefits.
Another thing I see as an example of markdown being slightly more readable: Unlike roff, not needing to escape some typographical marks (like - to get a hyphen). And the better syntax highlighting support for stuff like bold, italics, and so on in Markdown.
Good question. I had an unreleased version of this project running on groff only for quite some time.
After using it for 25 or so applications, I got the feeling that having markdown as the "source of truth" was slightly easier for reading, checking, and diffing different versions. I've been using it with Markdown as a base and I'm happy with the results.
Basically, I found Groff's syntax slightly "heavier" than Markdown for everyday visual use.
Having said that, I know that a lot of the visual clutter issues can be fixed on the groff side. If you actually have a groff resume format that is very readable for you, I would like to take a look and maybe reevaluate if i'm doing groff the right way.
I guess the argument is: If you want human-readable archives, you can then pick txtar. But mongotar basically adds some of the tar features which were missing from txtar
Hey, absolute props for replying to my code by making a counter-code of your own!
I don't have the time to look into this right now, but wanted to say that this is the best I could hope of posting my random projects here: Having someone else tell you what they would do instead.
And for context, this was a weekend experiment. I wanted to try building "agentic stuff," and exploring the not-so-promising intersection of information theory, LLMs, and code quality.
Will edit later after I read yours.
Well, the typical use would be by local Agent subscription. But in theory any LLM could work, so long as it's made to follow the filesystem protocol that faaah expects.
There's a video in the repo with an example of how it works, plus a diagram.
Do you think rather than AI was used for most of the code? I don't think it was.
If what you're saying is that "vibe-coded" applies when "some AI was used", and that it's a bad thing, that's a valid opinion that I might agree with in some contexts (like an ethical one).
It's not, but some AI was used for the code. I think vibe coding it would have produced a very different (and larger) code base. What makes you think it's vibe coded?
Yes. The idea is that you can have any tool on one side (which expects an OpenAI-like LLM API, which is a bit of a de facto standard), and any LLM on the other side (which can be an agent subscription).
I used this, for example, to test GraphRAG locally (which is designed to make a lot of LLM API calls) by piping it to an agent subscription I already had (and not needing to buy expensive API tokens for the low volume I needed).
Thanks!
Yeah, I don't like agents either, so I'll take it. This just solved a real problem I had, so I went ahead and shared it
Well, the main reason why I post my projects is for people to tell me what alternatives I'm missing, so thanks for that.
I'm actually not that familiar with Kilo, but I believe it's an agent/IDE-extension, and that you can use different providers for it, including coding agents (I think this is what you were referring to.)
So basically my use case is more niche. I just had an external tool (Graphrag) that only worked with an LLM API, and I had just an agent subscription, so i built an agnostic protocol via the filesystem to make them work together.
It's agnostic because you can have any tool on one side (which expects an OpenAI-like LLM API), and any LLM on the other side (which can be an agent subscription).
Nothing in Kilo would have allowed me to get Graphrag working, I think.
What in particular? Maybe I can tell you.
My initial use case was testing graphrag locally, which might become relevant at work later on, so I generalized the thing I did to get it working through an agent subscription. Actually that usage is public too: https://github.com/sebastiancarlos/graphrag-faaah
Hey pmjv, thanks for dropping by! You're an absolute legend and I couldn't have made this (for better or worse) without your work.
Thanks for the feedback. I'm the author of the medium blog post too.
If you have any tips on where to find a better free voice, I'm all ears. I haven't tried chatterbox yet, that one might do it.
It could also be that the "direct blog post to video" format doesn't cut it. But I'm still experimenting with ways to generate effective multimedia out of my content.
Btw, this is my open-source pipeline, which I use to make the video and blog post out of the same source file: https://github.com/sebastiancarlos/hacker-press
Edit: Regarding "satire", that doesn't apply to this blog post in particular. But I did add some jokes here and there to keep the dry topic going.
That's a good point, yes.
No problem! Fwiw I think a lot of us identify with a lot of that character these days.
The article literally starts with "In 2026, the job market is tough. AI plunged us all into economic despair" (itself exaggerated, and a play on the typical "AI doomer" clickbait articles saying what we all know more dramatically, which is another can of worms).
Agreed. And in the article it isn't. He does get a job at the end.
But yeah, I can see how your reading of the article is valid. I'll sleep on it and see if I can do something about it.