Why does there need to be something else? That’s a powerful reason.
Markdown is subpar and has an awful steward—as evidenced by all the different “flavours” and degrees of support in existence—but we somehow made it work in a jumble of hacks and that’s what we have now. It’s crummy but gets the job done.
Even if AsciiDoc is technically superior, which it probably is, is it superior enough to justify the big players implementing and pushing for in more in places regular users have access too?
Opposing goals, the purpose of markdown is to have a nice looking plain text document that can be automatically typeset and asciidoc is to have a well structured plain text document that can be automaticly typeset.
Note that markdown's whole value proposition is that it is a nice looking plaintext format, it stinks at adding any sort of semantic value to a document. realistically if you care about your documentation you will use something better than markdown. The problem is adding better structure always makes the plain text ugly and hard to read, violating the whole point of markdown. that is to say, the many efforts to add better semantics to markdown don't appear to understand the point of markdown.
ASCII, by way of that character encoding standard, implies that dark age before writing and transmitting 'café' or 'Warschauer Straße' or '€10' or '¡olé!' just worked. Not a great marketing point.
So the first thing you are wondering when you read 'AsciiDoc' is, “Wait, does this mean it doesn't support anything but ASCII characters?”, regardless of whether or not that is true.
I think preventing. I don't think Ruby is a bad language, but I've never worked anywhere it was a first or even second class language. I like AsciiDoc, but it's a hard sell to convince people to manage an entire other language toolchain used for nothing but AsciiDoc. I don't think the distro packaged it, or maybe not a recent enough version, but I could be wrong.
It's already hard enough to get people to switch documentation formats, needing to manage another language for it is just a bridge too far everywhere I've worked. It would be an easier sell if it were statically compiled, or at least in an interpreted language we already used (Python or JS most places).
I think it’s both funny and fitting that a video game library opens in ‘early access’. Apart from adding more games over time, I don’t see the distinction between early access and an actual release.
The website is operational and usable, and will have more content added to it over time. Much like early access games. I wonder what the actual distinction is.
I would assume that they plan to throttle or otherwise keep a limit on number of users. In case things turn out to be harder on the backend than they were expecting. Could also be a fencepost in case they decide to shard users in a different way in the future and need to wipe people's save data?
I guess, if the analogy is tight, further content would just be "DLC" while moving from early access to a release would involve functional differences.
It's just vscode. I greatly prefer vim but the difference between vim + ai tools and cursor is just a no brainer in terms of productivity. Cursor isn't without problems but it's leagues ahead of the competition in my opinion.
pricing model, downtime, model support, pricing model, trying to take over the experience rather than assist within my experience. This last one is big, because Cursor wants to "reimagine" how developers work. The problem is the AIs are so far from being competent, they need to be kept on the sidelines and sub'd in occasionally, not be the quarterback. Oh, did I mention pricing model?
Personally, I just prefer the chat interface directly with no Cursor UI.
For me, the best way is to write my prompt in a txt file, away from anything to do with LLMs. The bottleneck is not the update of the files like Cursor is good at.
The bottleneck is the clarity of my thoughts.
I looked at your website.
How to get past Barry Schwartz ideas is the main problem that we face in 2025.
The Godel, Escher, Bach stuff to me is just nonsense. As a huge Bach fan boy it is from when Bach was massively overrated in cultural importance.
Hierarchy Theory? How about O-information?
Doesn't seem the O-information wiki entry exists, yet.
Because of the complaints? If so, yeah I get it. I'm there amongst them. It's kind of like Tesla FSD. There are often setbacks in releases and they definitely need to work on their communication with the community. That said, for the current price it's still worth any misgivings.
> What would the alternative be, as you can't just edit someone else's repo?
git push directly to the repository, in a separate branch namespace. This is how e.g. Gerrit works (pushing to a special ref makes a review, which is essentially the same as a pull request).
> Besides just cloning it and making the change locally, of course.
With GitHub, you cannot do that and get a PR out in the other end. You _must_ fork the repository into your own user/organization, push to that and then send a PR from that.
> git push directly to the repository, in a separate branch namespace. This is how e.g. Gerrit works (pushing to a special ref makes a review, which is essentially the same as a pull request).
And that `git push` doesn't need to be literally to the one and only repository. The SSH daemon could create an isolated environment (e.g. QEMU, FreeBSD jail, etc) that contains a copy of the repository, and run the commands in there. Obviously this could also check SSH keys and the requested git commands before doing anything at all.
It would probably be like what Sourcehut does[1] for letting you SSH into build VMs, but instead of a build it's a push. And they already do some logic during a push[2], so their code for those two places is probably a good place to look for how to implement this kind of thing.
>And that `git push` doesn't need to be literally to the one and only repository
I believe github already has their own implementation of a git server, so any commands submitted to it are abstracted away. They probably don't have a literal .git directory sitting on a server.
> git push directly to the repository, in a separate branch namespace. This is how e.g. Gerrit works (pushing to a special ref makes a review, which is essentially the same as a pull request).
What's the material difference? They build special mechanisms to provide access control for sub namespaces, which sound a lot like "forks".
Also i have no clue on their backend (iirc this info is researchable tho), but i wouldn't be surprised if functionally that is exactly how they do it anyway. It's all content addressed, i doubt they pay 2x the storage anytime you fork a repo right?
The big difference is how it is organized to the users viewing it. My GitHub account is littered with old forks of repositories I created just to submit one line patches; and despite the pull request to a repository in some sense being data relating to the history of that project -- certainly the discussion is all organized under that project -- if the original person actually removes fork to garbage collect their namespace the commits referenced in that pull request just disappear. Meanwhile, despite people now using the word "fork" for this purpose due to GitHub, there is actual value in being able to search for actual forks of a project--things that people are choosing to publicly distribute and maybe maintain themselves--rather than seeing a thousand repositories which exist only for the purpose of contributing a single patch (or, though this is another topic, people making the metaphorical equivalent of a "backup copy" within the strange set of semantics and ownership that is GitHub).
So not really. It's a special branch path that only exists for opening PRs, and doesn't do anything other than opening a PR. Yes, they share an object space, but so do forks in the first place, so any security issues with this flow are the same ones in the fork-PR flow.
It's still a security problem. If you put an unlocked outside door on your house and rely on the interior doors to be locked, we'd agree that's not safe, right? Or to keep it safe would require the kind of uniform attentiveness that people are generally bad at.
Folks with accounts "littered with old forks created to make PRs" may not have that kind of attentiveness.
I don't understand the analogy. What's the actual risk exposed by pushing to a magic branch path that opens a PR instead of actually creating a branch, compared to creating a fork and making a PR in that way?
