Re: [Nix-dev] xfce: 'lock screen' button

[Sergey Mironov]

Thanks! Didn't know i3lock. It works fine.

For the dm-tool, it doesn't work as expected

$ dm-tool lock
command does nothing and /var/log/lightdm.log contains [see below].
Could you please compare this snippet with your own?

Regards,
Sergey

--
/var/log/lightdm.log (after dm-tool)

[+1287786.07s] DEBUG: Seat: Locking
[+1287786.07s] DEBUG: Seat: Creating greeter session
[+1287786.07s] DEBUG: Seat: Setting XDG_SEAT=seat0
[+1287786.07s] DEBUG: Seat: Creating display server of type x
[+1287786.07s] DEBUG: Seat: Starting local X display
[+1287786.07s] DEBUG: Using VT 8
[+1287786.07s] DEBUG: DisplayServer x-1: Logging to /var/log/x-1.log
[+1287786.07s] DEBUG: DisplayServer x-1: Writing X server authority to
/run/root/:1
[+1287786.07s] DEBUG: DisplayServer x-1: Launching X Server
[+1287786.07s] DEBUG: Launching process 11047:
/nix/store/393nb5f1kg32f5m2z388ab2rfdny2q7d-xserver-wrapper :1 -auth
/run/root/:1 -nolisten tcp vt8 -novtswitch
[+1287786.07s] DEBUG: DisplayServer x-1: Waiting for ready signal from
X server :1
[+1287786.08s] DEBUG: Process 11047 exited with return value 1
[+1287786.08s] DEBUG: DisplayServer x-1: X server stopped
[+1287786.08s] DEBUG: Releasing VT 8
[+1287786.08s] DEBUG: DisplayServer x-1: Removing X server authority
/run/root/:1
[+1287786.08s] DEBUG: Seat: Display server stopped
[+1287786.08s] DEBUG: Seat: Stopping session
[+1287786.08s] DEBUG: Seat: Session stopped
[+1287786.08s] DEBUG: Seat: Stopping display server, no sessions require it



2014-05-16 17:32 GMT+04:00 Kirill Elagin :
> Yeah, and to ask lightdm to lock your session you do `dm-tool lock`.
>
>
> --
> Кирилл Елагин
>
>
> On Fri, May 16, 2014 at 11:06 AM, Domen Kožar  wrote:
>>
>> That's how I override default:
>>
>> $ type -P xflock4
>> /home/ielectric/bin/xflock4
>>
>> $ cat /home/ielectric/bin/xflock4
>> scrot /tmp/screen_locked.png
>> convert /tmp/screen_locked.png -scale 10% -scale 1000%
>> /tmp/screen_locked.png
>> killall -SIGUSR1 dunst
>> DISPLAY=:0.0 i3lock -i /tmp/screen_locked.png --nofork -d
>> killall -SIGUSR2 dunst
>>
>>
>>
>> On Fri, May 16, 2014 at 8:56 AM, Sergey Mironov  wrote:
>>>
>>> Hi. A question to Xfce gurus:
>>>
>>> In my current config the 'lock screen' button performs no action. If I
>>> install xscreensaver, the button will run it, but the login prompt
>>> window looks a bit .. Xy.  Does anybody know how to connect 'lock
>>> screen' button with lightdm display manager?
>>>
>>> Regards,
>>> Sergey
>>> ___
>>> nix-dev mailing list
>>> nix-dev@lists.science.uu.nl
>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Restructuring of the Wiki

[Alex Berg]

I've not heard that we have a "specially designated team of wiki
maintainers".

If we want to use user permissions as an indicator of responsibility, we
have 3 wiki admins: Chexxor, Goibhniu, and EelcoDolstra:


On Mon, May 19, 2014 at 12:45 PM, Kirill Elagin  wrote:

> On Mon, May 19, 2014 at 7:13 PM, Alex Berg  wrote:
>
>> Thanks for the link to past discussion on this topic, Cillian. That was a
>> good discussion. Also, thank you, Third3ye, for contributing to the wiki
>> effort and raising Nix wiki awareness.
>>
>> ### On the Nix Wiki
>>
>> A wiki is a low-barrier way to build a database of eventually consistent
>> and correct info. Good topics for this info includes history, design, and
>> purpose of entities, in addition to explaining relationships between topics.
>>
>> In Nix project's case, several areas need such info - OS-management,
>> software building/distribution, and development environments using Nix. Our
>> wiki is not only for NixOS info, nor is it only for developers to document
>> their additions to Nix code. It's a place for seeing the big picture, of
>> both Nix and as it is meant to relate to other things. This includes its
>> relationship with ubiquitous software design problems or just to help out
>> our current projects.
>>
>> If you want to add a page which doesn't fit in this picture, should you
>> forget about adding it? No. Just add it somewhere. Wiki maintainers, who
>> care about enforcing the wiki's design, can assimilate it by moving it to
>> the right place and editing it's style.
>>
>
> Do we have a specially designated team of wiki maintainers?
>
>
>>  Now, having said that, do we still need to change how the wiki works?
>> I'm pretty happy with our wiki. We have zero spam now. We just need to
>> complete it's redesign, and new users should feel more confident adding
>> content to the skeleton. We've been playing with a new main page [1], but
>> it's not finished.
>>
>> The OP also mentioned machine-generated pages. I'm not a fan. This
>> implies two different places to visit to edit the wiki, which distracts
>> from the wiki's purpose of a *central* place for community-maintained
>> big-picture info.
>>
>> ### On Moving the Wiki
>>
>> This thread *does* include some discussion on moving the wiki, and I
>> didn't comment in last year's thread on that topic, so I'll do so now.
>>
>> Requirements for software which enables this kind of information
>> compilation:
>>
>> 1) Easy for non-coders to contribute
>> 2) Searchable
>> 3) History of content, to recover lost info
>>
>> Nice to have:
>>
>> 3) Organizable into topics
>> 4) Software is easy to maintain
>> 5) Content is portable
>>
>
> It looks like any reasonable wiki software can offer all of this. Gollum
> and Gitit included.
>
>
>> If we want to become "A GitHub Project", we can
>> - Use their wiki system
>> - Create a new Git repo called "wiki". We can edit and commit file
>> changes in GitHub browser UI.
>>
>> I'm not a fan of becoming "A GitHub Project", because the Nix project is
>> bigger than just GitHub. How so? We have several other web sites which are
>> essential to Nix, including Hydra, online manuals, and the Nix homepage
>> itself. Also, fads come and go, and GitHub may be just a fad.
>>
>
> Again, staying inside GitHub for their wiki is not necessary. We can run
> their wiki (Gollum) standalone on nixos.org domain and be happy with it.
> So, basically, if we are talking about migration we just have to choose
> one of the engines which all seem to be nice. Again, I feel that opening an
> issue for this would be handy.
>
> But wiki organisation is way more important than the engine used. And I'd
> like to hear more on this topic. It would be nice to have guides on writing
> wiki articles and wiki organisation.
> Are those available anywhere in written form?
>
>
>> I *am* a fan, however, of having a file-based backend which still keeps
>> file history. I would *only* consider such a system if they can be
>> maintained entirely through a browser. It looks like these are both
>> features of Gitit.
>>
>> [1] https://nixos.org/wiki/Main_Page_B
>>
>>
>>
>> On Mon, May 19, 2014 at 9:29 AM, Anderson Torres <
>> torres.anderson...@gmail.com> wrote:
>>
>>> About documentation itself, I find the format of famous "FreeBSD
>>> Handbook" (http://www.freebsd.org/doc/handbook/) very appealing. It can
>>> be used as a guide to our wiki or even a book on its own.
>>>
>>> Also, a thing I miss in the wiki is a 'hacking guide' inside Nixpkgs and
>>> Nix programming in general. I would like if some functions as callPackage,
>>> recurseIntoAttrs were more explained with examples or whatever.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 2014-05-19 8:22 GMT-03:00 Cillian de Róiste 
>>> :
>>>
>>> For reference, here's the discussion from the last time the topic of
 changing wiki platform came up, last year:
 http://lists.science.uu.nl/pipermail/nix-dev/2013-March/010800.html
 ___
 nix

Re: [Nix-dev] Restructuring of the Wiki

[Kirill Elagin]

On Mon, May 19, 2014 at 7:13 PM, Alex Berg  wrote:

> Thanks for the link to past discussion on this topic, Cillian. That was a
> good discussion. Also, thank you, Third3ye, for contributing to the wiki
> effort and raising Nix wiki awareness.
>
> ### On the Nix Wiki
>
> A wiki is a low-barrier way to build a database of eventually consistent
> and correct info. Good topics for this info includes history, design, and
> purpose of entities, in addition to explaining relationships between topics.
>
> In Nix project's case, several areas need such info - OS-management,
> software building/distribution, and development environments using Nix. Our
> wiki is not only for NixOS info, nor is it only for developers to document
> their additions to Nix code. It's a place for seeing the big picture, of
> both Nix and as it is meant to relate to other things. This includes its
> relationship with ubiquitous software design problems or just to help out
> our current projects.
>
> If you want to add a page which doesn't fit in this picture, should you
> forget about adding it? No. Just add it somewhere. Wiki maintainers, who
> care about enforcing the wiki's design, can assimilate it by moving it to
> the right place and editing it's style.
>

Do we have a specially designated team of wiki maintainers?


> Now, having said that, do we still need to change how the wiki works? I'm
> pretty happy with our wiki. We have zero spam now. We just need to complete
> it's redesign, and new users should feel more confident adding content to
> the skeleton. We've been playing with a new main page [1], but it's not
> finished.
>
> The OP also mentioned machine-generated pages. I'm not a fan. This implies
> two different places to visit to edit the wiki, which distracts from the
> wiki's purpose of a *central* place for community-maintained big-picture
> info.
>
> ### On Moving the Wiki
>
> This thread *does* include some discussion on moving the wiki, and I
> didn't comment in last year's thread on that topic, so I'll do so now.
>
> Requirements for software which enables this kind of information
> compilation:
>
> 1) Easy for non-coders to contribute
> 2) Searchable
> 3) History of content, to recover lost info
>
> Nice to have:
>
> 3) Organizable into topics
> 4) Software is easy to maintain
> 5) Content is portable
>

It looks like any reasonable wiki software can offer all of this. Gollum
and Gitit included.


> If we want to become "A GitHub Project", we can
> - Use their wiki system
> - Create a new Git repo called "wiki". We can edit and commit file changes
> in GitHub browser UI.
>
> I'm not a fan of becoming "A GitHub Project", because the Nix project is
> bigger than just GitHub. How so? We have several other web sites which are
> essential to Nix, including Hydra, online manuals, and the Nix homepage
> itself. Also, fads come and go, and GitHub may be just a fad.
>

Again, staying inside GitHub for their wiki is not necessary. We can run
their wiki (Gollum) standalone on nixos.org domain and be happy with it.
So, basically, if we are talking about migration we just have to choose one
of the engines which all seem to be nice. Again, I feel that opening an
issue for this would be handy.

But wiki organisation is way more important than the engine used. And I'd
like to hear more on this topic. It would be nice to have guides on writing
wiki articles and wiki organisation.
Are those available anywhere in written form?


> I *am* a fan, however, of having a file-based backend which still keeps
> file history. I would *only* consider such a system if they can be
> maintained entirely through a browser. It looks like these are both
> features of Gitit.
>
> [1] https://nixos.org/wiki/Main_Page_B
>
>
>
> On Mon, May 19, 2014 at 9:29 AM, Anderson Torres <
> torres.anderson...@gmail.com> wrote:
>
>> About documentation itself, I find the format of famous "FreeBSD
>> Handbook" (http://www.freebsd.org/doc/handbook/) very appealing. It can
>> be used as a guide to our wiki or even a book on its own.
>>
>> Also, a thing I miss in the wiki is a 'hacking guide' inside Nixpkgs and
>> Nix programming in general. I would like if some functions as callPackage,
>> recurseIntoAttrs were more explained with examples or whatever.
>>
>>
>>
>>
>>
>>
>>
>> 2014-05-19 8:22 GMT-03:00 Cillian de Róiste :
>>
>> For reference, here's the discussion from the last time the topic of
>>> changing wiki platform came up, last year:
>>> http://lists.science.uu.nl/pipermail/nix-dev/2013-March/010800.html
>>> ___
>>> nix-dev mailing list
>>> nix-dev@lists.science.uu.nl
>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>
>>
>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.scie

Re: [Nix-dev] Restructuring of the Wiki

[Alex Berg]

Thanks for the link to past discussion on this topic, Cillian. That was a
good discussion. Also, thank you, Third3ye, for contributing to the wiki
effort and raising Nix wiki awareness.

### On the Nix Wiki

A wiki is a low-barrier way to build a database of eventually consistent
and correct info. Good topics for this info includes history, design, and
purpose of entities, in addition to explaining relationships between topics.

In Nix project's case, several areas need such info - OS-management,
software building/distribution, and development environments using Nix. Our
wiki is not only for NixOS info, nor is it only for developers to document
their additions to Nix code. It's a place for seeing the big picture, of
both Nix and as it is meant to relate to other things. This includes its
relationship with ubiquitous software design problems or just to help out
our current projects.

If you want to add a page which doesn't fit in this picture, should you
forget about adding it? No. Just add it somewhere. Wiki maintainers, who
care about enforcing the wiki's design, can assimilate it by moving it to
the right place and editing it's style.

Now, having said that, do we still need to change how the wiki works? I'm
pretty happy with our wiki. We have zero spam now. We just need to complete
it's redesign, and new users should feel more confident adding content to
the skeleton. We've been playing with a new main page [1], but it's not
finished.

The OP also mentioned machine-generated pages. I'm not a fan. This implies
two different places to visit to edit the wiki, which distracts from the
wiki's purpose of a *central* place for community-maintained big-picture
info.

### On Moving the Wiki

This thread *does* include some discussion on moving the wiki, and I didn't
comment in last year's thread on that topic, so I'll do so now.

Requirements for software which enables this kind of information
compilation:

1) Easy for non-coders to contribute
2) Searchable
3) History of content, to recover lost info

Nice to have:

3) Organizable into topics
4) Software is easy to maintain
5) Content is portable

If we want to become "A GitHub Project", we can
- Use their wiki system
- Create a new Git repo called "wiki". We can edit and commit file changes
in GitHub browser UI.

I'm not a fan of becoming "A GitHub Project", because the Nix project is
bigger than just GitHub. How so? We have several other web sites which are
essential to Nix, including Hydra, online manuals, and the Nix homepage
itself. Also, fads come and go, and GitHub may be just a fad.

I *am* a fan, however, of having a file-based backend which still keeps
file history. I would *only* consider such a system if they can be
maintained entirely through a browser. It looks like these are both
features of Gitit.

[1] https://nixos.org/wiki/Main_Page_B



On Mon, May 19, 2014 at 9:29 AM, Anderson Torres <
torres.anderson...@gmail.com> wrote:

> About documentation itself, I find the format of famous "FreeBSD Handbook"
> (http://www.freebsd.org/doc/handbook/) very appealing. It can be used as
> a guide to our wiki or even a book on its own.
>
> Also, a thing I miss in the wiki is a 'hacking guide' inside Nixpkgs and
> Nix programming in general. I would like if some functions as callPackage,
> recurseIntoAttrs were more explained with examples or whatever.
>
>
>
>
>
>
>
> 2014-05-19 8:22 GMT-03:00 Cillian de Róiste :
>
> For reference, here's the discussion from the last time the topic of
>> changing wiki platform came up, last year:
>> http://lists.science.uu.nl/pipermail/nix-dev/2013-March/010800.html
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Mate Desktop on NixOS - some help needed

[Anderson Torres]

So simple...I am feeling shy :/
Many thanks, Vladimír!

By the way, I created a branch, mate-on-nixos, on my local mirror. It has
only mate-common for now, and I will not pull-request it until I feel it is
complete.


2014-05-18 7:02 GMT-03:00 Vladimír Čunát :

> On 05/17/2014 09:34 PM, Anderson Torres wrote:
>
>> mate-common = callPackage ./core/mate-common.nix;
>>
>
> You're missing braces, as callPackage takes two parameters, e.g.:
> mate-common = callPackage ./core/mate-common.nix { };
>
> Vlada
>
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Restructuring of the Wiki

[Anderson Torres]

About documentation itself, I find the format of famous "FreeBSD Handbook" (
http://www.freebsd.org/doc/handbook/) very appealing. It can be used as a
guide to our wiki or even a book on its own.

Also, a thing I miss in the wiki is a 'hacking guide' inside Nixpkgs and
Nix programming in general. I would like if some functions as callPackage,
recurseIntoAttrs were more explained with examples or whatever.







2014-05-19 8:22 GMT-03:00 Cillian de Róiste :

> For reference, here's the discussion from the last time the topic of
> changing wiki platform came up, last year:
> http://lists.science.uu.nl/pipermail/nix-dev/2013-March/010800.html
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Restructuring of the Wiki

[Cillian de Róiste]

For reference, here's the discussion from the last time the topic of
changing wiki platform came up, last year:
http://lists.science.uu.nl/pipermail/nix-dev/2013-March/010800.html
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Restructuring of the Wiki

[Mateusz Kowalczyk]

On 05/19/2014 10:03 AM, Kirill Elagin wrote:
> Small note first:
> s/Markdown/PandocMarkdown/
> (and this `s/.../.../` thing has to do with `sed`, in case you
> wonder). I guess many of the NixOS people live in the Haskell world, and
> `pandoc` is the tool of choice there. The good news is that it supports
> _both_ reading and writing MediaWiki markup, so it is possible to write
> markdown, convert to MediaWiki markup and upload it into MediaWiki's
> database, edit it in MediaWiki and then convert back to markdown.

Pandoc seems to be a popular choice outside of Haskell community too.

> And this brings us to the question: why wiki? There are other good ways of
> writing documentation, just to name: man-pages, GNU info (I have no idea
> what's that and how to use that and just freak out when a tool's man page
> says “for more details check the info”), plain text files. But for some
> reason wiki is widely used. Do you know why? I don't. But won't it be the
> case that by moving wiki editing to the console you'll break this magical
> wiki charm that makes people write articles?
> 

It's true that there are other ways to provide documentation, but the
appeal of wiki is that all you need is a browser and we've all used
wikipedia before. It's easy to edit (don't need to send patches
somewhere then wait), easy to distribute and easy to view.

Granted, browsers nowadays are not the most light-weight things but most
of us use one.

> 
> Anyway, this sounds like a great project: wiki backed by markdown+VCS
> instead of MediaWiki markup+database. I like the idea, and here are the
> good news: this thing already exists! https://github.com/gollum/gollum
> Even more awesome: https://github.com/jgm/gitit.
> 
> So, basically, I can extract three separate goals from your large text:
> 
> * Get rid of MediaWiki to make it possible to edit articles in text
> editors. Solution: migration to Gitit.
> * Create a Nix expression that will checkout HEAD of the wiki repository
> and prepare it to be deployed locally (web server serving wiki). Solution:
> create it, but after Gitit migration.
> * Better documentation. Solution: ???.
> 
> Now to the main point. I doubt that it's possible to get a good
> community-written wiki by enforcing some kind of policy (like, ”DO write
> articles, and DO write _good_ articles”). I think, everyone agrees that the
> best Linux wikis out there are Gentoo Wiki and ArchWiki and I'm not sure
> that they became so awesome because someone wanted them to. It all happens
> automagically once there is a critical mass of users. I'm afraid that there
> are just not many enough NixOS users to have a really good wiki right now.
> But, yeah, we can try at least.
> 

I agree that rather than there being some technical reason for why
Gentoo wiki is much bigger and complete than NixOS wiki is simply the
number of users. Also notably, Gentoo offers a lot of customisation so
the wiki often has to go in depth about different setups, which is great!

> 
> P.S. I'm not sure that NixOS wiki is a good place to this “For The
> Uninitiated” page. I don't know, maybe linux.about.com or StackOverflow?
> 
> 
> --
> Кирилл Елагин
> 
> 
> On Mon, May 19, 2014 at 10:33 AM, Third3ye  wrote:
> 
>>  Hey there!
>>
>> I'm Third3ye and you've probably seen me troll the #NixOS channel like a
>> pro. If you don't want to read this rather large e-mail about the wiki, how
>> about answering a few questions?
>>
>>1. *Do you edit or add to the Wiki? If so how frequently?*
>>2. *Would you like to see the Wiki expanded upon?*
>>3. *Would you prefer an alternative way of editing Wiki pages, say
>>through a terminal or through github?*
>>
>> Now, on with the talky-talk...
>>  Lately I've been talking to Chexxor and have been looking for a way to
>> contribute while I get to learn nixpkgs, C++ and QT to work on a more
>> ambitious project. I've worked within computer management, UX research,
>> web-design, GUI design and a wee bit of scripting/programming in projects,
>> small and mid-size businesses --- yet I have much MOAR to learn (I need
>> moar...!)
>>
>> Chexxor has let me know that he is currently undergoing (a seemingly
>> undermanned) restructuring of the NixOS Wiki. I've decided to throw my hand
>> in to this by doing one thing and suggesting another: contributing
>> individually to the Wiki and to start a project of automating the
>> assembling and building of the wiki, including data (but excluding
>> userbase), through nixpkgs.
>>
>> The reason behind the suggestion is that the NixOS ecosystem is perfect
>> for deployment, especially within intranet scenarios (nix+hydra+disnix? Yes
>> please). Unfortunately you are often left without direct access to internet
>> in these cases (due to security). You're then often forced to use your
>> phone or get to a computer that has access to internet.
>>
>> The Wiki for Linux distribution is in some cases the only manual or a

Re: [Nix-dev] Binary cache for local hydra server

[Rob Vermaas]

Hi,

I want to set up a binary cache for my locally running hydra and I would
> be very thankful for some suggestions how to do that.
> The binary cache should provide what http://cache.nixos.org provides for
> http://hydra.nixos.org, that is it should work as a fast way to serve
> the nix-packages build by hydra.
>
> Looking through the configurations for delft/lucifer I found that it is
> executing a local script "mirror-nixos-stable.sh" in a service and I
> assume that script transfers the built nix packages to the binary cache.
> Can anyone tell me more about the "magic" that that script is doing?
> Also, what would be the best server to use as binary cache? E.g. what is
> being used for cache.nixos.org? Or anything else I should/could consider
> or think about?
>

The scripts for updating the channel, creating the binary caches can be
found here: https://nixos.org/repos/nix/release/trunk/channels/

For cache.nixos.org we actually use an S3 bucket with Amazon CloudFront in
front of it. So no servers involved in serving this content. You don't need
a big machine though to server such static contents.

Cheers,
Rob
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Restructuring of the Wiki

[Kirill Elagin]

FTR just so that people don't get confused: GitHub's wiki is Gollum which I
mentioned.

Maybe it would be more handy to open an issue in nixpkgs for discussing
wiki engines?


--
Кирилл Елагин


On Mon, May 19, 2014 at 12:24 PM, Marc Weber  wrote:

> Just a very small comment:
> Different wiki systems have been proposed earlier (when we ha da spam
> problem). Two were important (to me):
>
> 1) http://vim-wiki.mawercer.de/wiki/index.html (based on git), no login
>   required (I haven't had any spam yet) - and if it happens it would be
>   trivial to add non standard blockers
>
> 2) github's wiki
>
> Both have one big advantage:
> Because they can be managed via "git" they could be attached to nixpkgs
> version or you could have them on disk and edit them with your favorite
> text editor.
>
> Eg you could grep nixpkgs and the wiki in one go to replace names and so
> on.
>
> I do use the wiki to add content which probably should not be contained
> in the manual so that I don't have to tell people twice.
> Examples are: Introduction to hack-nix, how to find help, comparison of
> 'automatically updating sources' implementations and such.
>
> While "changing things" can be done easily - I somehow still fail to see
> which is the big problem you want to solve by your proposal.
>
> Marc Weber
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Restructuring of the Wiki

[Marc Weber]

Just a very small comment:
Different wiki systems have been proposed earlier (when we ha da spam
problem). Two were important (to me):

1) http://vim-wiki.mawercer.de/wiki/index.html (based on git), no login
  required (I haven't had any spam yet) - and if it happens it would be
  trivial to add non standard blockers

2) github's wiki

Both have one big advantage:
Because they can be managed via "git" they could be attached to nixpkgs
version or you could have them on disk and edit them with your favorite
text editor.

Eg you could grep nixpkgs and the wiki in one go to replace names and so
on.

I do use the wiki to add content which probably should not be contained
in the manual so that I don't have to tell people twice.
Examples are: Introduction to hack-nix, how to find help, comparison of
'automatically updating sources' implementations and such.

While "changing things" can be done easily - I somehow still fail to see
which is the big problem you want to solve by your proposal.

Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Binary cache for local hydra server

[Thomas Strobel]

Hi there!

I want to set up a binary cache for my locally running hydra and I would
be very thankful for some suggestions how to do that.
The binary cache should provide what http://cache.nixos.org provides for
http://hydra.nixos.org, that is it should work as a fast way to serve
the nix-packages build by hydra.

Looking through the configurations for delft/lucifer I found that it is
executing a local script "mirror-nixos-stable.sh" in a service and I
assume that script transfers the built nix packages to the binary cache.
Can anyone tell me more about the "magic" that that script is doing?
Also, what would be the best server to use as binary cache? E.g. what is
being used for cache.nixos.org? Or anything else I should/could consider
or think about?


In advance, many thanks for your help!

  Thomas
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Restructuring of the Wiki

[Kirill Elagin]

Small note first:
s/Markdown/PandocMarkdown/
(and this `s/.../.../` thing has to do with `sed`, in case you
wonder). I guess many of the NixOS people live in the Haskell world, and
`pandoc` is the tool of choice there. The good news is that it supports
_both_ reading and writing MediaWiki markup, so it is possible to write
markdown, convert to MediaWiki markup and upload it into MediaWiki's
database, edit it in MediaWiki and then convert back to markdown.

And this brings us to the question: why wiki? There are other good ways of
writing documentation, just to name: man-pages, GNU info (I have no idea
what's that and how to use that and just freak out when a tool's man page
says “for more details check the info”), plain text files. But for some
reason wiki is widely used. Do you know why? I don't. But won't it be the
case that by moving wiki editing to the console you'll break this magical
wiki charm that makes people write articles?


Anyway, this sounds like a great project: wiki backed by markdown+VCS
instead of MediaWiki markup+database. I like the idea, and here are the
good news: this thing already exists! https://github.com/gollum/gollum
Even more awesome: https://github.com/jgm/gitit.

So, basically, I can extract three separate goals from your large text:

* Get rid of MediaWiki to make it possible to edit articles in text
editors. Solution: migration to Gitit.
* Create a Nix expression that will checkout HEAD of the wiki repository
and prepare it to be deployed locally (web server serving wiki). Solution:
create it, but after Gitit migration.
* Better documentation. Solution: ???.

Now to the main point. I doubt that it's possible to get a good
community-written wiki by enforcing some kind of policy (like, ”DO write
articles, and DO write _good_ articles”). I think, everyone agrees that the
best Linux wikis out there are Gentoo Wiki and ArchWiki and I'm not sure
that they became so awesome because someone wanted them to. It all happens
automagically once there is a critical mass of users. I'm afraid that there
are just not many enough NixOS users to have a really good wiki right now.
But, yeah, we can try at least.


P.S. I'm not sure that NixOS wiki is a good place to this “For The
Uninitiated” page. I don't know, maybe linux.about.com or StackOverflow?


--
Кирилл Елагин


On Mon, May 19, 2014 at 10:33 AM, Third3ye  wrote:

>  Hey there!
>
> I'm Third3ye and you've probably seen me troll the #NixOS channel like a
> pro. If you don't want to read this rather large e-mail about the wiki, how
> about answering a few questions?
>
>1. *Do you edit or add to the Wiki? If so how frequently?*
>2. *Would you like to see the Wiki expanded upon?*
>3. *Would you prefer an alternative way of editing Wiki pages, say
>through a terminal or through github?*
>
> Now, on with the talky-talk...
>  Lately I've been talking to Chexxor and have been looking for a way to
> contribute while I get to learn nixpkgs, C++ and QT to work on a more
> ambitious project. I've worked within computer management, UX research,
> web-design, GUI design and a wee bit of scripting/programming in projects,
> small and mid-size businesses --- yet I have much MOAR to learn (I need
> moar...!)
>
> Chexxor has let me know that he is currently undergoing (a seemingly
> undermanned) restructuring of the NixOS Wiki. I've decided to throw my hand
> in to this by doing one thing and suggesting another: contributing
> individually to the Wiki and to start a project of automating the
> assembling and building of the wiki, including data (but excluding
> userbase), through nixpkgs.
>
> The reason behind the suggestion is that the NixOS ecosystem is perfect
> for deployment, especially within intranet scenarios (nix+hydra+disnix? Yes
> please). Unfortunately you are often left without direct access to internet
> in these cases (due to security). You're then often forced to use your
> phone or get to a computer that has access to internet.
>
> The Wiki for Linux distribution is in some cases the only manual or a
> great source of extra information regarding special scenarios. It is also a
> go-to source for maintenance, installation and configuration within these
> special scenarios. The idea is to create a nixpkg that automatically builds
> the NixOS wiki and that can import updated wiki pages via a simple update
> through nixpkgs.
>
> But the problem is the Wiki needs updating and this needs people to add
> the relevant information. I'm guessing here, but I'm pretty sure that most
> maintainers and pullers more often than not forgo adding extra information
> to the Wiki that might not have a home in the manual. This is probably due
> to the fact that this means involving another system of publishing and
> maintaining data (visa vi using the WikiMedia interface and engine). I
> suggest we bridge that gap and make nixos-wiki an ad-hoc version of the
> Wiki that can be built and depl

Re: [Nix-dev] Restructuring of the Wiki

[Mateusz Kowalczyk]

On 05/19/2014 08:33 AM, Third3ye wrote:
> Hey there!
> 
> I'm Third3ye and you've probably seen me troll the #NixOS channel like a 
> pro. If you don't want to read this rather large e-mail about the wiki, 
> how about answering a few questions?
> 
>  1. *Do you edit or add to the Wiki? If so how frequently?*

If I do something that's missing, I will add it.

>  2. *Would you like to see the Wiki expanded upon?*

Yes, there are definitely many pages missing. I had to create a page on
something as commonly used as NFS the other day!

>  3. *Would you prefer an alternative way of editing Wiki pages, say
> through a terminal or through github?*

Can't say it's something I really miss, in the end one can copy + paste
from their text editor.

> Now, on with the talky-talk...
> 
> Lately I've been talking to Chexxor and have been looking for a way to 
> contribute while I get to learn nixpkgs, C++ and QT to work on a more 
> ambitious project. I've worked within computer management, UX research, 
> web-design, GUI design and a wee bit of scripting/programming in 
> projects, small and mid-size businesses --- yet I have much MOAR to 
> learn (I need moar...!)
> 
> Chexxor has let me know that he is currently undergoing (a seemingly 
> undermanned) restructuring of the NixOS Wiki. I've decided to throw my 
> hand in to this by doing one thing and suggesting another: contributing 
> individually to the Wiki and to start a project of automating the 
> assembling and building of the wiki, including data (but excluding 
> userbase), through nixpkgs.
> 
> The reason behind the suggestion is that the NixOS ecosystem is perfect 
> for deployment, especially within intranet scenarios (nix+hydra+disnix? 
> Yes please). Unfortunately you are often left without direct access to 
> internet in these cases (due to security). You're then often forced to 
> use your phone or get to a computer that has access to internet.
> 
> The Wiki for Linux distribution is in some cases the only manual or a 
> great source of extra information regarding special scenarios. It is 
> also a go-to source for maintenance, installation and configuration 
> within these special scenarios. The idea is to create a nixpkg that 
> automatically builds the NixOS wiki and that can import updated wiki 
> pages via a simple update through nixpkgs.
> 
> But the problem is the Wiki needs updating and this needs people to add 
> the relevant information. I'm guessing here, but I'm pretty sure that 
> most maintainers and pullers more often than not forgo adding extra 
> information to the Wiki that might not have a home in the manual. This 
> is probably due to the fact that this means involving another system of 
> publishing and maintaining data (visa vi using the WikiMedia interface 
> and engine). I suggest we bridge that gap and make nixos-wiki an ad-hoc 
> version of the Wiki that can be built and deployed anywhere.
> 
> This can be done in two ways:
> 
>  1. including a "doc.wiki" (or similar) expression that allows adding
> data to the relevant to a page and section of the Wiki. This would
> effectively remove any necessity for a developer or maintainer to
> move beyond the nixpkgs system, which I think is the most effective
> approach. But this would also mean adding code to nix, which I'm not
> sure will be the preferred choice.
>  2. Making a simple pkg that has a folder structure similar to the
> structure of the wiki. default.nix would then serve as an index file
> and wiki pages would simply be markdown files. A
> developer/maintainer could then just add to the wiki page from
> terminal and commit for review.
> 
> The reason I suggest these options is because I think that the Wiki 
> needs some serious attention and is in dire need of a restructuring. I 
> think that by starting the discussion of including the wiki maintaining 
> process as a package or as a part of nix expression would be a good 
> start to find alternative ways of including people in the Wiki editing 
> process.
> 
> Additional additionally!
> I've created a few pages and would like some feedback from the community 
> in regards to subject and structure. Here are the pages:
> 
> *The UDX initiative*:
> https://nixos.org/wiki/UDX_Initiative
> *For the uninitiated* (a cheat-sheet in regards to Linux/Unix and Nix(OS):
> https://nixos.org/wiki/For_The_Uninitiated
> *KDE* (example of a simple wiki page):
> https://nixos.org/wiki/KDE
> 
> /"The UDX inititative"/ is a theoretical approach to the user & 
> developer relationship and how to most effectively facilitate the 
> processes between them. In the FOSS world there are many initiatives and 
> movements within these parameters. I think it would be a good idea to 
> assemble some of these ideas in to a page that is ment to teach both 
> users and developers how to achieve an optimal state of productivity.
> 
> /"For the uniititated"/ is something I'm working on because I never took 
> the ti