Live data from Hacker News

Wiki.js

wiki.js.org

181–190 of 213 posts

Re: Wiki.js

#181
post #46

This is exciting. A compelling FOSS alternative to Atlassian Confluence was sorely needed. Mediawiki has some UX and RBAC challenges that makes it difficult to scale to large organizations.

"Some"? The fact that you have to manually access the database backend in order to change a password is a joke, among many.

If its your own password you can change from the web interface. If it is someone else's password you can send a password reset email from the web interface.

To actually set someone else's password to a specific value does require running a command line script (not the same as going into db). In my view that is a reasonable security-convinence trade off.

In any case, i would assume a large org would use a single-sign-on extension and not mediawiki's native user management, which would make MW's password management moot.

Disclaimer: am mediawiki developer

Re: Wiki.js

#182

Slightly related PSA: Everyone should consider running a wiki locally just for yourself. It's like being able to organize your brain. I just got into it two days ago and basically spent the whole weekend dumping things into it in a way I can actually browse and revisit, like the short stories I'd written, spread out across Notes.app and random folders. You don't need to run WAMP, MySQL, Apache, phpmyadmin or anything…

I almost went with MediaWiki, but ended up with DokuWiki. The fresh install of MediaWiki is 154 MB (!) and it's not exactly lightweight. DokuWiki is 10.9 MB and all content is saved in plain text files. Very attractive. However, backlinks are not possible without hacks. A wiki without backlinks is kind of lame and I could very well use my good old plain text files. Have you run in to trouble when updating MediaWiki,…

What do you mean by backlinks are not possible? Do you mean in DokuWiki? Each page has a "What links here" button that shows backlinks - that feature is builtin.

Re: Wiki.js

#183

Can we please not have SPA's eat wikis, too? Text-only content does not need... (checking...) 6.3 MB of JavaScript to display (checking...) 3.3 KB of text. Blank pages with JavaScript disabled or in non-mainstream browsers is a really terrible experience for content so plainly simple to display.

Wikis also don't need (or indeed, even permit) cumbersome Git and PR-based workflows just to get changes into the "wiki". Better for it to be a single-page app that actually implements a wiki, than to provide a service that doesn't actually support wikis but has no qualms about throwing the word around anyway.

Re: Wiki.js

#184

Earlier quoted context omitted.

It also requires a browser that supports HTML for some reason, instead of being an API you communicate with through CURL POST requests.

I was hoping for a tty interface over telnet with plain ascii output.

Other technologies are slow and insecure, and I have disabled them on my system. Too much memory usage.

Please ensure that if you mention your service or system on HN it works over telnet and outputs plain ascii.

Re: Wiki.js

#186

In case anyone was wondering, the dependencies are: Node.js 10.12 or later MySQL, MariaDB, PostgreSQL, MSSQL or SQLite3 Is it possible to install and run all of these as a non-root user?

I think you only need 1 DB, not all of them.

Re: Wiki.js

#187
post #158

Earlier quoted context omitted.

I've wondered whether the term directly evolved from this sort of joke list that was popular to pass around on the early internet: http://www.personal.psu.edu/sxt104/program1.html

I assume it evolved not long after guns existed, and likely grew in the military :)

"Shooting yourself in the foot," sure, but if you look up "footgun" it seems to only be programming slang. What I was suggesting with the above comment was that this sort of list might have popularized the metaphor of shooting yourself in the foot in programming, which was then was subjected to hacker-style word manipulation.

Re: Wiki.js

#188

Earlier quoted context omitted.

So for complete clarification: If I hosted a wiki.js, say on a subdomain, unrelated to a commercial application's code at all, but lined to it (e.g. the "docs" section of navigation) would I need to disclose a) the source code of the wiki.js subdomain only, and any modifications we make to it b) the source code of wiki.js and the other proprietary app BOTH ?

Linking as in binary linking: yes (option b). Linking as in HTML A href link: no, only option a. Problem is that unless you are installing your servers by hand you end up re-packaging wiki.js and then your own packaging code and the modification on wiki.js as a build artefact are now supposed to be public as well.

I don't understand what you mean about packaging code.

Do you mean to distinguish between setting up an EC2 instance or digitalocean droplet type of thing versus using ansible/chef/etc orchestration among the servers? Implying you would have to publish the configs for all your servers?

That would make no sense, both from a practical perspective (publicly disclose server configs? those can include sensitive information), and a theoretical perspective (what does that have to do with the source code at all?).

Re: Wiki.js

#189
post #171
post #154

Earlier quoted context omitted.

If they are the sole copyright owners (no external contribution) or have SLAs, they can for any future version of the software. It is not uncommon, it is just hard as most doesn't have SLA to do this.

> If they are the sole copyright owners (no external contribution) That's not the scenario gary-kim laid out; you've failed to satisfy the constraints in the premise.

Read better, I'm not replying to him. I agree with him.

Re: Wiki.js

#190
post #123

Earlier quoted context omitted.

> It's a guarantee that the project will remain open source What are you talking about? They can change the license to a closed one from a certain version in the future.

For future versions, not past versions.

Not sure why I'm getting downvoted, but this does not change the fact that yes, licenses can be changed. You disliking it does not make it wrong.
Post reply on HN