20after4
Not the op, and while your criticism of their negativity may be somewhat justified, the ask is kind of silly. There are a bunch of well known alternatives:
Self-hosted free software:
Gerrit <https://www.gerritcodereview.com> Phorge <https://we.phorge.it>
SaaSsy:
Codeberg <https://codeberg.org> SourceHut <https://sr.ht/>
There are a lot more, of course, these are just the ones I have experience with.
Like seriously, Mozilla could probably make some serious revenue with this. I only wonder if it would open them up to getting sued, somehow.
If education is all dependent on the use of AI, then we're cutting off everyone but the most wealthy from access to education. Seems very regressive to me.
1. This is an assumption but I think it's fairly well established that current LLM prices are far below operating costs of inference, so prices will go up, maybe not 10x but some multiple > 1
More prior art: xcfile²
I've used xc³ for a long time now and it's fairly solid. The idea of runnable markdown is definitely useful. A lot of projects have attempted it and none that I've seen have achieved what I'd call perfection, however, xc gets close enough for my needs.
I'll check out Ledge a bit more thoroughly and give some feedback if I can think of anything constructive. I think xc is probably more suited for my uses, however, I do like electrobun and that seems like a good runtime to build something like this.
Here's what I like about xc:
1. It's built with GO and brings all the power of go's template engine. The portability of go's runtime means that it is just one binary and doesn't have any crazy runtime dependencies.
2. It has a built in dependency system so that each block of code can be predicated on another block completing. It can also ensure that each block in a dependency chain runs just once.
I've built a sort of configuration management system for my home infrastructure with config files in a git repo and all the deployment scripts and dependencies directly in the readme. I use it to maintain and deploy changes to my router, firewall rules, dhcp and dns, git repositories, and various containers.
- Local go server to index everything into sqlite or postgres
- browser extension to send the DOM for indexing.
- This happens after each page is finished rendering, so client side rendering doesn't break, and it doesn't require fetching the url a second time on the back-end.
- Filter rules to control what gets indexed (basic url regex patterns, nothing too fancy)
- Text-based query interface for terminal dwellers like me.
- Local file indexing that actually works well so that you can search your history and your documents in one place.
- Custom extractors for understanding specific sites and file formats.
Mostly as disclosure that I worked there. Not trying to make a point about anything at all. Just offering my observations as a former employee.
Anyone can be a Wikipedia editor, assuming you haven't done something egregious and gotten a lifetime ban.
It takes no time at all to set up an editor account and you don't even have to divulge your real identity to do so. The Wikimedia Foundation appears to go to great lengths to defend their editors and has gone to court to defend their editors' rights to pseudo-anonymity.
Note: I am a former employee of Wikimedia and everything I saw while I worked there supports that the vast majority of staff, including management, care a great deal about protecting editors, promoting free knowledge, and making the project as open and inclusive as possible.
Discussions of unionization have been ongoing for many years, they only gained momentum recently due to the some recent events that, AFAIK, have very little to do with overall job security or any threat from economic forces or AI eating Wikipedia's lunch.
There are a lot of things to criticize about Wikipedia but lack of financial planning probably isn't top of the list.
(there were multiple bands with that name over the years)