Wiki for musl?

Wiki for musl?

[Rich Felker]

Hi all,

Jeremy's offered to help set up us (*) a wiki for musl, which could be
used for recording all of the disorganized and as-yet-unrecorded
community knowledge about package compatibility, patches needed,
common issues, troubleshooting, etc.

My experience using wikis is fairly limited and I have no no idea
which wiki software is best, so I figured I'd best ask the community
who'll (hopefully) be using if you have preferences. While I know lots
of us lean towards the choice that's the least bloated/ugly behind the
scenes, it would probably also be worth considering which choices are
nicest from a standpoint of making contributing/editing a pleasant
experience. :-)


Rich

Re: Wiki for musl?

[Jeremy Huntwork]

On Wednesday, June 13, 2012 at 2:14 PM, Rich Felker wrote:
> My experience using wikis is fairly limited and I have no no idea
> which wiki software is best, so I figured I'd best ask the community
> who'll (hopefully) be using if you have preferences. While I know lots
> of us lean towards the choice that's the least bloated/ugly behind the
> scenes, it would probably also be worth considering which choices are
> nicest from a standpoint of making contributing/editing a pleasant
> experience. :-)
> 

I'm sure there's better ones out there, and I'm looking forward to hearing other suggestions, but a very lightweight and simple one while still fairly usable is dokuwiki: http://www.dokuwiki.org/dokuwiki

JH

Re: Wiki for musl?

[Daniel Cegiełka]

2012/6/13 Rich Felker <dalias@aerifal.cx>:
>
> My experience using wikis is fairly limited and I have no no idea
> which wiki software is best, so I figured I'd best ask the community
> who'll (hopefully) be using if you have preferences. While I know lots
> of us lean towards the choice that's the least bloated/ugly behind the
> scenes, it would probably also be worth considering which choices are
> nicest from a standpoint of making contributing/editing a pleasant
> experience. :-)

Openwall uses dokuwiki:

http://www.dokuwiki.org/dokuwiki

Daniel

Re: Wiki for musl?

[Szabolcs Nagy]

* Daniel Cegie?ka <daniel.cegielka@gmail.com> [2012-06-13 20:24:55 +0200]:
> http://www.dokuwiki.org/dokuwiki
> 

ugh powered by php.. :)

my solution would be a public git repo of static .html pages

but i can see how that might not be the most convenient interface..

Re: Wiki for musl?

[Jeremy Huntwork]

On Wednesday, June 13, 2012 at 2:39 PM, Szabolcs Nagy wrote:
> ugh powered by php.. :)

Yeah I expected there might be that reaction. :) I'm looking around for a similar one in Python, but haven't found it yet.

JH

Re: Wiki for musl?

[Daniel Cegiełka]

>> http://www.dokuwiki.org/dokuwiki
>
> ugh powered by php.. :)
>
> my solution would be a public git repo of static .html pages

Great idea! :D

> but i can see how that might not be the most convenient interface..

Re: Wiki for musl?

[Kurt H Maier]

On Wed, Jun 13, 2012 at 08:39:57PM +0200, Szabolcs Nagy wrote:
> * Daniel Cegie?ka <daniel.cegielka@gmail.com> [2012-06-13 20:24:55 +0200]:
> > http://www.dokuwiki.org/dokuwiki
> > 
> 
> ugh powered by php.. :)
> 
> my solution would be a public git repo of static .html pages
> 
> but i can see how that might not be the most convenient interface..

There are middle grounds: http://ikiwiki.info/

Re: Wiki for musl?

[Ivan Kanakarakis]

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

that's kinda of what suckless.org uses.
they have an hg repo which contains markdown [0] pages,
that get rendered as almost fully static html with werc [1]

  [0]: http://daringfireball.net/projects/markdown/
  [1]: http://werc.cat-v.org/wiki/suckless/

I do like this idea, git-based repo with a nice markup language,
but I do also see how that might not be the most convenient
interface as nsz mentioned.


On 13 June 2012 21:49, Daniel Cegiełka <daniel.cegielka@gmail.com> wrote:

> >> http://www.dokuwiki.org/dokuwiki
> >
> > ugh powered by php.. :)
> >
> > my solution would be a public git repo of static .html pages
>
> Great idea! :D
>
> > but i can see how that might not be the most convenient interface..
>



-- 
*Ivan c00kiemon5ter V Kanakarakis*  >:3

[-- Attachment #2: Type: text/html, Size: 1548 bytes --]

Re: Wiki for musl?

[Jeremy Huntwork]

On Wednesday, June 13, 2012 at 2:51 PM, Kurt H Maier wrote:
> There are middle grounds: http://ikiwiki.info/

This looks like it might be nice. 

JH

Re: Wiki for musl?

[Rich Felker]

On Wed, Jun 13, 2012 at 03:20:58PM -0400, Jeremy Huntwork wrote:
> On Wednesday, June 13, 2012 at 2:51 PM, Kurt H Maier wrote:
> > There are middle grounds: http://ikiwiki.info/
> 
> This looks like it might be nice. 

Looks interesting. I like that its login (at least for their sandbox)
is OpenID based; making and storing passwords for each new
site/service is a huge pain.

Rich

Re: Wiki for musl?

[Justin Cormack]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

On Wed, Jun 13, 2012 at 7:51 PM, Kurt H Maier <khm-lists@intma.in> wrote:

> On Wed, Jun 13, 2012 at 08:39:57PM +0200, Szabolcs Nagy wrote:
> > * Daniel Cegie?ka <daniel.cegielka@gmail.com> [2012-06-13 20:24:55
> +0200]:
> > > http://www.dokuwiki.org/dokuwiki
> > >
> >
> > ugh powered by php.. :)
> >
> > my solution would be a public git repo of static .html pages
> >
> > but i can see how that might not be the most convenient interface..
>
> There are middle grounds: http://ikiwiki.info/
>

Or git repos of markdown rather than html.

[-- Attachment #2: Type: text/html, Size: 1071 bytes --]

Re: Wiki for musl?

[Rich Felker]

On Wed, Jun 13, 2012 at 03:20:58PM -0400, Jeremy Huntwork wrote:
> On Wednesday, June 13, 2012 at 2:51 PM, Kurt H Maier wrote:
> > There are middle grounds: http://ikiwiki.info/
> 
> This looks like it might be nice. 

To elaborate on this and my original thoughts, I think it would
actually be nice to make choices that reflect the values of the musl
project - both being built on clean/light/efficient software, but also
having a modern interface/feel/usability. The latter is not just a
practical consideration for our own usage, but an _image_
consideration; our public image should give the feeling that "clean
and light doesn't have to be old-fashioned". Using git and OpenID are
nice elements from that standpoint. Otherwise the web interface of
ikiwiki doesn't really stand out as anything special, but it's also
not particularly broken or ugly, at least not in any way I noticed.

Rich

Re: Wiki for musl?

[Rich Felker]

On Wed, Jun 13, 2012 at 04:02:00PM -0400, Jeremy Huntwork wrote:
> On Wednesday, June 13, 2012 at 3:54 PM, Rich Felker wrote:
> > To elaborate on this and my original thoughts, I think it would
> > actually be nice to make choices that reflect the values of the musl
> > project - both being built on clean/light/efficient software, but also
> > having a modern interface/feel/usability. The latter is not just a
> > practical consideration for our own usage, but an _image_
> > consideration; our public image should give the feeling that "clean
> > and light doesn't have to be old-fashioned". Using git and OpenID are
> > nice elements from that standpoint. Otherwise the web interface of
> > ikiwiki doesn't really stand out as anything special, but it's also
> > not particularly broken or ugly, at least not in any way I noticed.
> 
> You should be able to add custom CSS to anything it produces such
> that it looks/feels any way you want it to.

I was thinking more along the lines of AJAX for realtime update of the
preview alongside the text (ala Stack Overflow), submission without
reloading the whole page, etc. Not just visual presentation of the
page.

Rich

Re: Wiki for musl?

[Jeremy Huntwork]

On Wednesday, June 13, 2012 at 3:54 PM, Rich Felker wrote:
> To elaborate on this and my original thoughts, I think it would
> actually be nice to make choices that reflect the values of the musl
> project - both being built on clean/light/efficient software, but also
> having a modern interface/feel/usability. The latter is not just a
> practical consideration for our own usage, but an _image_
> consideration; our public image should give the feeling that "clean
> and light doesn't have to be old-fashioned". Using git and OpenID are
> nice elements from that standpoint. Otherwise the web interface of
> ikiwiki doesn't really stand out as anything special, but it's also
> not particularly broken or ugly, at least not in any way I noticed.
> 


You should be able to add custom CSS to anything it produces such that it looks/feels any way you want it to.

JH

Re: Wiki for musl?

[Jeremy Huntwork]

On Wednesday, June 13, 2012 at 4:00 PM, Rich Felker wrote:
> I was thinking more along the lines of AJAX for realtime update of the
> preview alongside the text (ala Stack Overflow), submission without
> reloading the whole page, etc. Not just visual presentation of the
> page.

Gotcha. Well if you're going that route, maybe you want to consider github :).

It offers custom project pages, issue tracking, a wiki and baked in collaboration http://pages.github.com/

An example of a project using it:
Public project page: http://libarchive.github.com/
Dev resource page: https://github.com/libarchive/libarchive

JH

Re: Wiki for musl?

[Luca Barbato]

On 06/13/2012 08:14 PM, Rich Felker wrote:
> Hi all,
> 
> Jeremy's offered to help set up us (*) a wiki for musl, which could be
> used for recording all of the disorganized and as-yet-unrecorded
> community knowledge about package compatibility, patches needed,
> common issues, troubleshooting, etc.

I'd abuse github wiki-git, if we are lazy we use directly github, if we
want our own we could deploy (all the bits are opensource iirc)

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

Re: Wiki for musl?

[nwmcsween]

There's gollum which githib uses for git based wiki but it requires ruby (good and bad) a good alternative would simply use a c based document converter (I think there's a project called sundown that does just that for markdown), convert on post receive hooks into html and create a mailing list for musl-wiki.

On Jun 13, 2012, at 11:14 AM, Rich Felker <dalias@aerifal.cx> wrote:

> Hi all,
> 
> Jeremy's offered to help set up us (*) a wiki for musl, which could be
> used for recording all of the disorganized and as-yet-unrecorded
> community knowledge about package compatibility, patches needed,
> common issues, troubleshooting, etc.
> 
> My experience using wikis is fairly limited and I have no no idea
> which wiki software is best, so I figured I'd best ask the community
> who'll (hopefully) be using if you have preferences. While I know lots
> of us lean towards the choice that's the least bloated/ugly behind the
> scenes, it would probably also be worth considering which choices are
> nicest from a standpoint of making contributing/editing a pleasant
> experience. :-)
> 
> 
> Rich

Re: Wiki for musl?

[Ivan Kanakarakis]

[-- Attachment #1: Type: text/plain, Size: 1375 bytes --]

yep, this [0] is gollum
this [1] is sundown

  [0]: https://github.com/github/gollum
  [1]: https://github.com/tanoku/sundown


On 13 June 2012 23:38, <nwmcsween@gmail.com> wrote:

> There's gollum which githib uses for git based wiki but it requires ruby
> (good and bad) a good alternative would simply use a c based document
> converter (I think there's a project called sundown that does just that for
> markdown), convert on post receive hooks into html and create a mailing
> list for musl-wiki.
>
> On Jun 13, 2012, at 11:14 AM, Rich Felker <dalias@aerifal.cx> wrote:
>
> > Hi all,
> >
> > Jeremy's offered to help set up us (*) a wiki for musl, which could be
> > used for recording all of the disorganized and as-yet-unrecorded
> > community knowledge about package compatibility, patches needed,
> > common issues, troubleshooting, etc.
> >
> > My experience using wikis is fairly limited and I have no no idea
> > which wiki software is best, so I figured I'd best ask the community
> > who'll (hopefully) be using if you have preferences. While I know lots
> > of us lean towards the choice that's the least bloated/ugly behind the
> > scenes, it would probably also be worth considering which choices are
> > nicest from a standpoint of making contributing/editing a pleasant
> > experience. :-)
> >
> >
> > Rich
>



-- 
*Ivan c00kiemon5ter V Kanakarakis*  >:3

[-- Attachment #2: Type: text/html, Size: 2066 bytes --]

Re: Wiki for musl?

[Kurt H Maier]

On Wed, Jun 13, 2012 at 04:00:06PM -0400, Rich Felker wrote:
> 
> I was thinking more along the lines of AJAX for realtime update of the
> preview alongside the text (ala Stack Overflow), submission without
> reloading the whole page, etc. Not just visual presentation of the
> page.

There are such things possible with ikiwiki.  If your interested in
current status, you can glance over the discussions on ikiwiki.info,
such as http://ikiwiki.info/todo/mdwn_preview/ 

The specific feature you're talking about on stack overflow hsa been
cloned a bunch of times in general-use libraries.  For an example of
that, see http://code.google.com/p/pagedown/source/browse/ -- which can
be shoved into just about any wiki program.  (incidentally, ikiwiki uses
markdown by default, but any (or multiple) markup compilers can be used.
the traditional 'easy' setup involves a post-commit hook on the server
that triggers a recompile of the wiki whenever someone checks in the
source.)

The default ikiwiki theme and css is very sparse, but there are quite a
few drop-in replacements for them that look fancy and ajaxy.  

Please keep in mind that lots of people still don't like using this sort
of thing.  For the record, I'm one of them.  

Re: Wiki for musl?

[Jeremy Huntwork]

On Jun 13, 2012, at 7:10 PM, Kurt H Maier <khm-lists@intma.in> wrote:

> There are such things possible with ikiwiki.  If your interested in
> current status, you can glance over the discussions on ikiwiki.info,
> such as http://ikiwiki.info/todo/mdwn_preview/
>
> The specific feature you're talking about on stack overflow hsa been
> cloned a bunch of times in general-use libraries.  For an example of
> that, see http://code.google.com/p/pagedown/source/browse/ -- which can
> be shoved into just about any wiki program.  (incidentally, ikiwiki uses
> markdown by default, but any (or multiple) markup compilers can be used.
> the traditional 'easy' setup involves a post-commit hook on the server
> that triggers a recompile of the wiki whenever someone checks in the
> source.)

I do really like the simplicity of it. I'm curious enough that I'll
probably set it up somewhere tonight to play around with. No hurt in
taking a test drive!

JH

Re: Wiki for musl?

[Rich Felker]

On Wed, Jun 13, 2012 at 07:09:47PM -0400, Kurt H Maier wrote:
> On Wed, Jun 13, 2012 at 04:00:06PM -0400, Rich Felker wrote:
> > 
> > I was thinking more along the lines of AJAX for realtime update of the
> > preview alongside the text (ala Stack Overflow), submission without
> > reloading the whole page, etc. Not just visual presentation of the
> > page.
> 
> There are such things possible with ikiwiki.  If your interested in
> current status, you can glance over the discussions on ikiwiki.info,
> such as http://ikiwiki.info/todo/mdwn_preview/ 
> 
> The specific feature you're talking about on stack overflow hsa been
> cloned a bunch of times in general-use libraries.  For an example of

I assume you're talking about the live preview. What about submitting
changes without reloading the page? To me that makes a big difference
in the usability impression - avoiding the discontinuity of the screen
disappearing for a second, the scrollbar getting reset, etc.

> that, see http://code.google.com/p/pagedown/source/browse/ -- which can
> be shoved into just about any wiki program.  (incidentally, ikiwiki uses
> markdown by default, but any (or multiple) markup compilers can be used.
> the traditional 'easy' setup involves a post-commit hook on the server
> that triggers a recompile of the wiki whenever someone checks in the
> source.)

Nice, so it's all static aside from edits?

> The default ikiwiki theme and css is very sparse, but there are quite a
> few drop-in replacements for them that look fancy and ajaxy.  

It's not that I want things to "look ajaxy". I don't mind if they look
like the first websites from the early 90s with no styling, default
fonts, no custom buttons, etc., but I do like having a responsive
interface without discontinuities. For pure static content broken into
logical pages, I'm perfectly happy without any ajax, but if the site
is something interactive/editable or an "application" of sorts, I
don't like it to feel like a second-class citizen in the world of
applications.

> Please keep in mind that lots of people still don't like using this sort
> of thing.  For the record, I'm one of them.  

Graceful fallback to non-AJAX when JS is disabled (or in browsers that
don't support JS) is of course a requirement for an accessible site.

Rich

Re: Wiki for musl?

[Kurt H Maier]

On Wed, Jun 13, 2012 at 08:21:40PM -0400, Rich Felker wrote:
> I assume you're talking about the live preview. What about submitting
> changes without reloading the page? To me that makes a big difference
> in the usability impression - avoiding the discontinuity of the screen
> disappearing for a second, the scrollbar getting reset, etc.

Since this was never meant to be how http works, this is a non-trivial
requirement.  In fact, it's a general case that the program must be
written from the ground up to support such behavior.  The only wiki
software I'm familiar with which provides this sort of functionality is
mojomojo.

> Nice, so it's all static aside from edits?

Not necessarily -- it *can* use cgi or fastcgi for lots of things.  But
in its default installation, yes.  One exception is for what they call
"discussion" pages -- those get dynamically managed, usually until some
cronjob dumps the data to disk and the site is recompiled.  Users don't
notice this process.

> It's not that I want things to "look ajaxy". I don't mind if they look
> like the first websites from the early 90s with no styling, default
> fonts, no custom buttons, etc., but I do like having a responsive
> interface without discontinuities. 

This is what I meant by "look ajaxy."  http is a fetch/display protocol;
html is a markup language designed to be rendered once.  dynamic
document alteration and xmlhttprequest are what ajax is all about.

> For pure static content broken into
> logical pages, I'm perfectly happy without any ajax, but if the site
> is something interactive/editable or an "application" of sorts, I
> don't like it to feel like a second-class citizen in the world of
> applications.
> 
> Graceful fallback to non-AJAX when JS is disabled (or in browsers that
> don't support JS) is of course a requirement for an accessible site.

That graceful degradation is a unicorn that has never been caught.  The
de facto solution that web people have adopted is in the style of
google: AJAX wherever possible, with a failover site written in regular
HTML.  The two front ends share no components and will double your
development and maintenance costs up front.  Recently Google has begun
to drop the HTML alternatives; GMail is a notable exception.  You should
consider whether it's worth your time to support both front ends; most
places ignore the non-ajax crew.  I would prefer not to, but you'll
receive no acrimony from me if you make that decision.

Re: Wiki for musl?

[Rich Felker]

On Wed, Jun 13, 2012 at 11:10:06PM -0400, Kurt H Maier wrote:
> On Wed, Jun 13, 2012 at 08:21:40PM -0400, Rich Felker wrote:
> > I assume you're talking about the live preview. What about submitting
> > changes without reloading the page? To me that makes a big difference
> > in the usability impression - avoiding the discontinuity of the screen
> > disappearing for a second, the scrollbar getting reset, etc.
> 
> Since this was never meant to be how http works, this is a non-trivial
> requirement.  In fact, it's a general case that the program must be
> written from the ground up to support such behavior.  The only wiki

See below...

> > It's not that I want things to "look ajaxy". I don't mind if they look
> > like the first websites from the early 90s with no styling, default
> > fonts, no custom buttons, etc., but I do like having a responsive
> > interface without discontinuities. 
> 
> This is what I meant by "look ajaxy."  http is a fetch/display protocol;
> html is a markup language designed to be rendered once.  dynamic
> document alteration and xmlhttprequest are what ajax is all about.

I understand how it works.

> > Graceful fallback to non-AJAX when JS is disabled (or in browsers that
> > don't support JS) is of course a requirement for an accessible site.
> 
> That graceful degradation is a unicorn that has never been caught.  The
> de facto solution that web people have adopted is in the style of
> google: AJAX wherever possible, with a failover site written in regular
> HTML.  The two front ends share no components and will double your
> development and maintenance costs up front.  Recently Google has begun

Just because this is the way broken sites are done doesn't mean it has
to be that way. Suppose instead you do something like this. When the
client sends the submission to the server, the server generates the
updated contact then does a DOM-level diff of the old and new
versions, then sends a representation of the diff across to the
client-side js that incorporates it into the DOM there.

No ugly duplication, eh? And the ajax code is nearly 100% generic and
site-generic.

Rich

Re: Wiki for musl?

[Conrad Pankoff]

Hi, "web person" here. I'm going to have to disagree with part of this.

On 14/06/2012, at 1:10 PM, Kurt H Maier wrote:
>> For pure static content broken into
>> logical pages, I'm perfectly happy without any ajax, but if the site
>> is something interactive/editable or an "application" of sorts, I
>> don't like it to feel like a second-class citizen in the world of
>> applications.
>> 
>> Graceful fallback to non-AJAX when JS is disabled (or in browsers that
>> don't support JS) is of course a requirement for an accessible site.
> 
> That graceful degradation is a unicorn that has never been caught.  The
> de facto solution that web people have adopted is in the style of
> google: AJAX wherever possible, with a failover site written in regular
> HTML.  The two front ends share no components and will double your
> development and maintenance costs up front.  Recently Google has begun
> to drop the HTML alternatives; GMail is a notable exception.  You should
> consider whether it's worth your time to support both front ends; most
> places ignore the non-ajax crew.  I would prefer not to, but you'll
> receive no acrimony from me if you make that decision.

I've personally written a few sites that work exactly this way - but from the opposite direction (I think the marketing guys call it "progressive enhancement"). By default, they are regular old HTML and no crazy ajax stuff. Then some JavaScript comes along and applies behavioural changes to the page to enable the fun stuff.

In saying this, however, it's not a trivial task to put together a site in this fashion.

Regards,
Conrad

Re: Wiki for musl?

[Szabolcs Nagy]

* Rich Felker <dalias@aerifal.cx> [2012-06-13 23:46:00 -0400]:
> Just because this is the way broken sites are done doesn't mean it has
> to be that way. Suppose instead you do something like this. When the
> client sends the submission to the server, the server generates the
> updated contact then does a DOM-level diff of the old and new
> versions, then sends a representation of the diff across to the
> client-side js that incorporates it into the DOM there.
> 
> No ugly duplication, eh? And the ajax code is nearly 100% generic and
> site-generic.
> 

i don't like when websites change under my feet

i imagine if someone else modifies the page you
still get the updates so the page can change
while you are reading it..

and the back button does not work anymore

then when a proxy modifies the page (eg to remove
ads or tidy up the html) then the patching will fail

and dom-level diff is not enough anyway:
the content can be a huge wall of text which is a
single node in the dom i guess, so you need more
granularity

i'm not sure if this idea is feasible at all

Re: Wiki for musl?

[Conrad Pankoff]

Hi, again, "web person" here to clear up a misunderstanding.

On 14/06/2012, at 5:55 PM, Szabolcs Nagy wrote:

> and the back button does not work anymore

Welcome to the wonderful world of the history API. In modern browsers (i.e. FF4+ and anything that uses WebKit) you can use the pushState method on the history object to update the URL in the browser without actually shoving the user off to a new page. On older browsers, the location.hash parameter can be used to achieve a similar (but not identical) effect. Both these techniques preserve the back/forward behaviours of the browser.

Regards,
Conrad