Wiki.js
111–120 of 213 posts
Re: Wiki.js
#112Earlier quoted context omitted.
Is the suggestion here that, say I was in the business of selling proprietary software, by running Wiki.js and making it accessible to the public that the copyleft license would then apply to my proprietary software?
If you package it with your software, then that might be the case unless you had negotiated other licencing terms first. Simply hosting it with your information in would not have any such effect, but many commercial entities avoid anything xGPL just-in-case. In this case perhaps because they see a time that they might later want to package and distribute documentation that is in the wiki without converting it to some…
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 ?
Re: Wiki.js
#113docs.requarks.io, which is said to be using Wiki.js, straight up doesn't load without Javascript, and even with Javascript enabled it's a multi-page application that just feels slower browsing page to page than your average 10-year-old mediawiki install (probably also heavier on the backend). Who exactly is asking for slower software?
> Running on the blazing fast Node.js engine Is Node.js that blazing-fast ?
It is based on V8 which in many (caveat: far from all) benchmarks comes out as the fastest JS engine, so by that definition in the realm of JS powered components it is pretty quick.
node.js solutions will often perform better than common configurations of other options too - Apache+PHP to pick one example out of the air. Then again, depending on the code other configurations of PHP might outperform Node.
Re: Wiki.js
#114Now that git has become ubiquitous, I prefer git with a self-hosted git-daemon instance. git , grep , awk , and sqlite make a strong set of tools for knowledge curation.
edit: minor grammar fix
Re: Wiki.js
#115Earlier quoted context omitted.
> Wiki.js, straight up doesn't load without Javascript I'm sorry but it's right there in the name
Because it uses Node.js in the backend. MediaWiki is written in PHP, but it does not require you to have PHP running in the client to work. As much as we could argue about whether no-js support really matters or not in 2020, the fact remains that having to having to load Vue.js and have it parse and render the frontend on the client is not really "lightweight", especially when the most popular competing products pre-…
I would say using js without having a no-js version is ok, if done correctly.
Re: Wiki.js
#116I used a Wiki for a long time. But I try to minimise maintenance ("foist it upon others"). I also try to resist the enthusiasm for Rube Goldberg machines and for installing bad tooling (such as PHP). Now that git has become ubiquitous, I prefer git with a self-hosted git-daemon instance. git , grep , awk , and sqlite make a strong set of tools for knowledge curation. edit: minor grammar fix
That said, DocuWiki is pretty decent to get up and running quickly.
Re: Wiki.js
#117Earlier quoted context omitted.
If you package it with your software, then that might be the case unless you had negotiated other licencing terms first. Simply hosting it with your information in would not have any such effect, but many commercial entities avoid anything xGPL just-in-case. In this case perhaps because they see a time that they might later want to package and distribute documentation that is in the wiki without converting it to some…
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 ?
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.
Re: Wiki.js
#118Earlier quoted context omitted.
> I just got into it two days ago This is the rub. I started a tiddlywiki last year, and stuck with it for several months, but now it has fallen to the wayside as too cumbersome.
This is the problem with a good percentage of advice and life/career hacks on HN -- they're always spoken of in the early, idealist stage. Before the reality has set in. Before the downsides have made their presence known. I've been in a number of firms with wiki knowledge systems. In 100% of the cases it was a wasteland of derelict knowledge that had been abandoned and was usually much more destructive than benefici…
I've thought about knowledge management a lot over the last 20 years, since I built a Wiki/bug tracker system (this was before anything except Bugzilla existed).
I think knowledge management systems can work if the "management" side is a side effect of their use.
Re: Wiki.js
#119Earlier quoted context omitted.
If you package it with your software, then that might be the case unless you had negotiated other licencing terms first. Simply hosting it with your information in would not have any such effect, but many commercial entities avoid anything xGPL just-in-case. In this case perhaps because they see a time that they might later want to package and distribute documentation that is in the wiki without converting it to some…
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 ?
If you allow self-hosting of your proprietary code by your users and the refers to your documentation server than this would still not trigger AGPL for the other code - you are not distributing wiki.js or parts of it. If you allow self hosting of the other code and include wiki.js for a local copy of your documentation then APGL might trigger.
Linking is meaning software linking, not referencing your own content displayed by the software. Think of it as the same difference between including using chunks of a paper in your own paper, or saying "as discussed in This Paper About This Thing (Him, Her, et. al, 2013)...". Or, as in this case the content is your's, referencing your own paper.
This potential confusion with the word "linking" (as natural languages are fairly dynamic beasts) is why people are sometimes overly fearful of AGPL and GPL (and often even LGPL) software.
Re: Wiki.js
#120Slightly 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…
- future proof (at least not only a one man project) - Fast search over all informations - Fast creation of quick notes (inbox) - Mobile iOS client
Currently I am stuck with Notion, which has a great 'database' concept. Which is fun to use. Sadly it's too slow. If I want to take a quick note on the go "Google for M6x40 Screws" I need 10-20 seconds with Notion.
I don't even mind paying for such service...