jasongrossman has quit [Ping timeout: 268 seconds]
pie__ has joined #nixos-chat
drakonis_ has joined #nixos-chat
veske has joined #nixos-chat
jasongrossman has joined #nixos-chat
jasongrossman has quit [Ping timeout: 245 seconds]
LnL has quit [Ping timeout: 258 seconds]
<joepie91[m]>
welp, my firefox is broken
<joepie91[m]>
stuck on white screen after starting
jasongrossman has joined #nixos-chat
<pie__>
welp
veske has quit [Quit: This computer has gone to sleep]
veske has joined #nixos-chat
<joepie91[m]>
had to nuke half of my profile to get it to work again :(
<joepie91[m]>
Firefox error messages are so absolutely and utterly useless...
<Shados>
joepie91[m]: Do/did you have any usercss at work?
<joepie91[m]>
not that I know of
<Shados>
OK. Because I've had usercss cause a similar issue. Eventually tracked it down to a regex used to match the urls to apply the usercss to -- there are *pathologically* bad performance corner-cases in the regex implementation, which can effectively freeze the whole browser.
<Shados>
Avoid backtracking regex engines where possible, folks.
<joepie91[m]>
Shados: oh, nah, here it occurred after a browser crash
Guest3555 has joined #nixos-chat
veske has quit [Ping timeout: 248 seconds]
veske has joined #nixos-chat
Guest3555 is now known as LnL
<srhb>
What the hell. You can't even partition normie OS'es like Centos and Ubuntu manually anymore?
<srhb>
What is this fisher price anaconda bs
<clever>
lol
__monty__ has joined #nixos-chat
<joepie91[m]>
srhb: there's a manual partitioning option afaik?
<srhb>
joepie91[m]: Yeah, it's a lie.
<srhb>
It'll do Something, but not give you nearly the control of fdisk/gdisk/parted.
<srhb>
Like, it has all sorts of weird ideas that perfectly valid setups are not.
<srhb>
And as far as I can see you can't ever choose to GPT partition, though if the disk just happened to have a GPT table already, it'll reuse that.
<sphalerite>
srhb: isn't there an option to escape to a shell?
<__monty__>
Careful though, there's no escape from $HELL.
veske has quit [Quit: This computer has gone to sleep]
veske has joined #nixos-chat
<srhb>
sphalerite: Yes, but I have no idea how to make the installer pick up the layout I'd like afterwards.
<srhb>
I think the only way to do it is through kickstarter, really, which is okay, but also hngghh.
<sphalerite>
srhb: or install it nixos-style, minus the lovely it-generates-config-for-you, with debootstrap?
<srhb>
sphalerite: Isn't that essentially what kickstarter is?
<sphalerite>
I have no idea :p
<srhb>
I might be losing touch with the mainstream too much :-P
<sphalerite>
you can run debootstrap from nixos though!
<srhb>
s/too much/just the right amount
<srhb>
I saw :-)
<sphalerite>
not sure baout installing centos though
<srhb>
I bet there's some "just execute kickstarter on this config file" way of doing it.
<srhb>
But in all honesty it can go die in a fire. :P
veske has quit [Quit: This computer has gone to sleep]
<sphalerite>
there's also a tool called FAI
<sphalerite>
no idea about the details of it though
<sphalerite>
except that it stands for Fully Automated Install[ation?]
<gchristensen>
srhb: this is a reason I like NixOS's installer *so* *much*.
<gchristensen>
you don't have to fight the GUI to convince it of what you want
<joepie91[m]>
OTOH: it could use a "use my entire disk, I don't care" option
<joepie91[m]>
:P
<gchristensen>
sure
<srhb>
gchristensen: Yeah, ditto.
<pie__>
joepie91[m], gotta love corrupt session data :C
<pie__>
joepie91[m], zfs snapshotS? :V
<joepie91[m]>
lol
<pie__>
joepie91[m], firefoox is one of the main reasons i went and actuall did the zfs thing
<pie__>
though i dont have autosnapshots yet
<pie__>
give me back my taaaabs
<eyJhb>
pie__ nope, mine
<eyJhb>
srhb What OS are you playing with?
<eyJhb>
Wtf, my terminal deadlocks sometimes when copying large files ...
<eyJhb>
URXVTd might not be the best thing I guess
<srhb>
eyJhb: Some toy operating system called "Centos"
<srhb>
It seems pretty useless at first glance.
<srhb>
*bitter*
<__monty__>
Maybe they follow redhat's installer and maybe that tries to limit the number of configurations they need to support?
<srhb>
Seems very likely.
<eyJhb>
Hahaha, I love how this comes directly after I talked with someone about replacing Redhat with centos :p
<eyJhb>
Lighten up srhb ! You know limits are there to save you from yourself, or..Something
<srhb>
I mean I'm sure nothing is worse than Red Hat.
<srhb>
:P
<eyJhb>
Queue aszlig, saying he coded a OS in brainfuck
veske has joined #nixos-chat
veske has quit [Read error: Connection reset by peer]
<srhb>
eyJhb: The person who is the direct cause of "free assignments" no longer being *that* free at DIKU is called Brainfuck.
<eyJhb>
I really want more of this - https://www.linuxondex.com/ , using a mobile as a full pleged operating system.... Is that what NixOS is aiming for? (phone)
<eyJhb>
srhb: that sounds about right! Migt consider doing it for our next semester know that you mention it ! ;)
<eyJhb>
now that**
<eyJhb>
But I am fairly certain, that we will be hated. Since we are helping a organisation in Africa.
<eyJhb>
But wait.. why are you playing with centos srhb ?
<srhb>
Dunno, coworker needed a hand :P
<eyJhb>
Did you end up walking away angry then? :p
<srhb>
I hand waved something like "maybe install a minimal system then fix it up with a real tool once you're booted into the actual system"
<srhb>
Very politely, of course.
<eyJhb>
_real tool_ :p - Was the problem the partiontables?
<srhb>
Yeah.
<srhb>
I mean, not that there were a lot of option for partitions/formatting either.
<pie__>
joepie91[m], dat thred tho
<eyJhb>
I feel like my, just do whatever works, way of doing partition management is not the best way to go now :p
<joepie91[m]>
pie__: ?
<pie__>
joepie91[m], papercuts thread keeps going. btw can you maybe clarify the "academic language" post
<joepie91[m]>
ah :)
<joepie91[m]>
pie__: and clarify in what sense?
<pie__>
it make sense but if someone asked me what is meant by that i wouldnt be able to give an example or anything
<pie__>
does it talk about monads or what
<joepie91[m]>
pie__: I don't have any concrete examples to hand, but there's a pretty extensive amount of documentation on how to write texts (in English) that are easily understood by most readers
<joepie91[m]>
in the case of the Nix* manuals, it's primarily an issue of jargon
<joepie91[m]>
pie__: ah, here, from the documentation for builtins.seq: "Evaluate e1, then evaluate and return e2. This ensures that a computation is strict in the value of e1."
<joepie91[m]>
that second phrase means absolutely /nothing/ to the average user, even to the average technical user
<joepie91[m]>
it assumes a host of background knowledge that is not really reasonable to expect outside of specific fields, and uses the word "strict" in a non-obvious way
<__monty__>
joepie91[m]: By average user, do you mean someone who doesn't and will never know what lazy evaluation semantics are?
<srhb>
Maybe average GNU/Linux user? I'm sure the average NixOS user knows quite a bit more about non-strict semantics.
<joepie91[m]>
__monty__: no.
<joepie91[m]>
srhb: that is the logical consequence if your documentation is inscrutable for people who don't have this background knowledge, yes :)
drakonis has joined #nixos-chat
<joepie91[m]>
this is the sort of documentation that makes someboy who is interested in the concept of NixOS, decide that "fuck it, this is too difficult for me" and leave
<joepie91[m]>
somebody*
<joepie91[m]>
so you will naturally end up with people who are either already familiar with all the jargon in the field, or who are stubborn enough to stick around and complain about the documentation (hi!)
<joepie91[m]>
and all the people who don't fall into those categories, will just... leave, quietly usually
<srhb>
joepie91[m]: I think you're using a bit too much hyperbole
<srhb>
At least, I would not want the NixOS manual, say, to become a manual on non-strict FP semantics.
<srhb>
Yet they are necessary knowledge for some level of NixOS usage.
<joepie91[m]>
I am not.
<joepie91[m]>
then the manual should explain them insofar they are needed.
<srhb>
I disagree.
<joepie91[m]>
that is what good documentation does; it makes a reasonable baseline assumption of the userbase, and provides all the background understanding necessary to understand how to use a thing.
<__monty__>
That was gonna be my next question. Won't those same peole just give up if they see the manual starts with a programming language tutorial?
<joepie91[m]>
and assuming that users will understand not just the semantics, but also the jargon of FP, means that you either a) have an unreasonable baseline, or b) have decided that users who want to use NixOS should just learn FP first
<joepie91[m]>
neither of which I am on board with
<joepie91[m]>
I also want to really strongly emphasize that knowing and understanding the concepts does not equal knowing the jargon
<joepie91[m]>
__monty__: no, they won't.
<joepie91[m]>
most people are fine with learning new things.
<joepie91[m]>
what they are not fine with, is constantly running into seemingly impenetrable walls.
<joepie91[m]>
and specialized jargon usage is a very effective way to put up such walls
<joepie91[m]>
because you are essentially locking away things that people /could/ have understood, behind a wall of (often unwritten) agreements within a particular tiny social circle about what things mean
<joepie91[m]>
it's a mechanism of social exclusion, when jargon is applied to tools that are supposed to be usable by non-developers
<joepie91[m]>
(where 'developers' is used as a broader term than just software developers)
<joepie91[m]>
this sort of shit is a big reason why academia often isn't taken very seriously outside of academia, btw.
<joepie91[m]>
some within academia realize this and actively try to make their work more accessible, but far too many people don't.
<__monty__>
I just wonder whether a reference style manual is the right place to give up on the precise language. I could see adding a glossary and linking all occurences to it. And then having a sort of beginner's guide or otherwise seperate documentation to get people up to scratch.
<joepie91[m]>
and frankly, if we ever want NixOS to be anything other than a distro for functional programmers and CS academics... the language usage in the community and documentation needs to be addressed.
<joepie91[m]>
__monty__: not only does that produce a big gap where anything beyond beginner usage is completely unattainable, it's also a totally unnecessary hack when you can just *make the documentation more readable to begin with*
<joepie91[m]>
glossaries are not a solution for regular users; they still require a heavey amount of cross-referencing
<__monty__>
What's your suggestion for the seq doc for example?
<joepie91[m]>
to change it to explain why it is useful, and what the mechanics are. given that after asking this in #nixos, it was very difficult to even get that sort of explanation interactively (and I am thus not convinced that my understanding of it is correct yet), I couldn't tell you on the spot how to rephrase it.
<joepie91[m]>
a commonly useful format for these sort of things is to inline a summarized explanation of something, one or two sentences, enough for somebody to recall the concept if they've ever read about it - and then reference the full explanation via eg. a link
<joepie91[m]>
in most cases, the summary is enough for the reader to recall the mechanics, without having to actively cross-reference. for the remaining cases, there's a link with more details.
<joepie91[m]>
importantly, that summary needs to be free of jargon (or at least, free of jargon that isn't very very widely understood)
<joepie91[m]>
(amongst the target demographic)
<drakonis>
colemickens: allowUnfree doesn't work because nix flakes does everything in pure mode, so it doesnt check the flag
<drakonis>
is it time to review nonfree-ness?
<drakonis>
how it is handled?
<__monty__>
That's exactly the problem I see with your suggestion. It seems like a simple question "Why'd I wanna use seq?" But an explanation that avoids all fp jargon is necessarily quite long, especially if you have to go all the way to why nix is lazy. As an experienced user it's annoying when the docs are much longer than you need. It's also hard to realize what bits of knowledge you're assuming. So both
<__monty__>
reading *and* writing such docs is hard for experienced people.
<__monty__>
There'd need to be lots of inexperienced people reporting issues with the documentation.
<joepie91[m]>
__monty__: as an experienced user, you can skim the documentation to find what you need. non-experienced users do not have that luxury.
<joepie91[m]>
and yes, writing good documentation is hard. but it sounds like you're using that as a reason not to attempt it :)
<joepie91[m]>
and inexperienced people aren't going to report issues with the documentation, because it is so impenetrable to them that, save for a few exceptions, they will simply give up and move on - it's not worth their time.
<__monty__>
No, I'm saying the ball is in the camp of the people that don't understand the docs.
<joepie91[m]>
bullshit.
<joepie91[m]>
sorry, but that is a lazy response.
<joepie91[m]>
the people who understand the tools are in the best position to fix the docs; they know what it should explain, they have a point of reference, a baseline.
<joepie91[m]>
it is ultimately their job to figure out how to effectively convey that knowledge to inexperienced users.
<joepie91[m]>
that is also the only way NixOS will ever get good docs.
<__monty__>
I agree they should be the ones to *write* the docs.
<joepie91[m]>
if people continue shrugging it off as "well, the people who don't understand it will just have to try and understand it harder", it will never change from where it is now.
<__monty__>
It's just that they don't have a clue *which* bits need improvement.
<joepie91[m]>
__monty__: great, so why are they arguing here about how it's difficult and how it's fine right now and how the ball is in the court of beginners.... rather than actively trying to improve their understanding of the issue?
<joepie91[m]>
like, the only way this situation is ever going to improve, is if the knowledgeable people start actively working on it
<joepie91[m]>
and generally recognize the need to do so
<joepie91[m]>
and that involves more work than saying "shrug, they'll just have to come to us with complaints"
<joepie91[m]>
because not only do new users not have the frame of reference to even be able to express the problem most of the time (experienced users do!), it's also unreasonable to expect them to invest that time
<joepie91[m]>
it's not /their/ project
<__monty__>
The only people that you can reasonably expect to invest their time in this are the ones that want nixos to be widespread though. Most are only interested in nixos because it enables them to do other cool stuff. Others are just interested in nixos an sich.
<joepie91[m]>
__monty__: then why even engage in the documentation discussion? just to highlight that /you/ understand it all? because if you don't care about NixOS becoming more widespread, it seems an utterly pointless discussion topic to hook onto
<joepie91[m]>
I mean, I was talking to pie__ about this, and you decided to engage in the discussion - so I'm going to assume that you at least principally share the objective of resolving usability issues to improve accessibility
<joepie91[m]>
if not, and you don't really care about it, then why get involved? it would just waste time and energy on everybody's part
<__monty__>
Even if I was not interested. The discussion could get you to rephrase it so the people who put effort into different parts of nixos don't feel discouraged.
<__monty__>
But yes, I *am* interested in improving this. I just feel like it's disproportionately difficult without "noobs" who are prepared to go through the docs and tell us what bits are problematic.
<__monty__>
biab
<joepie91[m]>
I mean, the reality is that there are not going to be enough people who a) bother trying NixOS, b) don't understand the documentation, c) understand the general concepts well enough to express what they don't understand, d) are willing to essentially do free work for something they might not even end up using (due to the poor docs experience), and e) have the time and energy to deal with all of this
<joepie91[m]>
it's hoping for a unicorn, it simply will not happen at any scale large enough to support a docs restructuring effort
<joepie91[m]>
so the remaining option, however difficult it is, is active outreach to better understand what people get stuck on, and quite importantly, assuming that every documentation complaint is valid unless proven otherwise
<joepie91[m]>
whereas right now, the implicit assumption - at least with a number of people - seems to be that every documentation complaint is invalid unless proven otherwise
<joepie91[m]>
which is a great way to quickly burn out those few unicorns that cross your path
<joepie91[m]>
even in this conversation - because I happen to be somebody who meets requirements A to D, but not quite E - I've run into that very problem
<joepie91[m]>
documentation complaints are challenged, fixing them is presented as "this is work, we don't really want to do this"
<joepie91[m]>
and I've now had to spend nearly an hour defending a documentation complaint
<joepie91[m]>
that is about an order of magnitude too long
<joepie91[m]>
and my time and energy is finite; I am willing to try addressing these issues and helping out finding documentation deficiencies and getting them fixed
<joepie91[m]>
but if I continue getting these sort of responses, then at one point I, too, will stop bothering and move on
<joepie91[m]>
potentially just fork the thing if I care about the technical aspects enough
<joepie91[m]>
thankfully there are a bunch of people within the NixOS community who care enough about improving accessibility for me to stick around, but I do have to say, quite frankly, that it's still balancing on the edge of whether I'm going to continue bothering
<joepie91[m]>
because there are still just too many cases where a problem description is met with a brick wall, a "but can you /prove/ that you are not talking shit"
<joepie91[m]>
for a contrasting example: see Matrix, where (UX/documentation) issues are treated as valid unless there's reason not to
<joepie91[m]>
and the results speak for themselves; usability is rapidly improving across the board, spec bugs are getting fixed within a span of weeks, not months or years
endformationage has joined #nixos-chat
<gchristensen>
joepie91[m]++
<{^_^}>
joepie91[m]'s karma got increased to 3
<eyJhb>
eyJhb++
<{^_^}>
eyJhb's karma got decreased to -3
<eyJhb>
:D
<joepie91[m]>
people file many of them, even the small ones, because they don't have to spend an hour defending each and every one
<joepie91[m]>
hell, I've filed like 5 or 6 of them in a single day
<joepie91[m]>
lol
<gchristensen>
joepie91[m]: I hope you don't find monty's perspective to be a unified perspective here
<joepie91[m]>
gchristensen: not unified, but also not a lone exception
<gchristensen>
right
<gchristensen>
it feels very obvious to me in what ways the docs are extremely lacking
<gchristensen>
even knowing the things it conveys
<gchristensen>
absent docs coverage need not even be involved in a discussion, there is so much :)
<joepie91[m]>
and also: if there were a consistently-accepting docs fixing effort, ie. where complaints would be taken as valid rather than needing to defend them, I'd likely be filing many issues, so there's your source of information :P
<joepie91[m]>
but there isn't, so I don't
<joepie91[m]>
I can't be confident that whatever docs issue I file will be taken seriously; maybe it will, maybe it won't, luck of the draw as far as I can tell
<gchristensen>
has it happened where they were not taken as valid?
<manveru>
joepie91[m]: i wonder if nixos will ever be usable by users that don't learn the language...
<joepie91[m]>
gchristensen: well, right at the start of this conversation in here; but more generally, I've run into a lot of questioning of usability-related issues
<joepie91[m]>
also on the issue tracker
<gchristensen>
yes definitely
<joepie91[m]>
where people seem to be difficult for the sake of being difficult, sometimes
<joepie91[m]>
manveru: I don't think that needs to be a goal
<joepie91[m]>
manveru: like I said, most people are perfectly willing to learn new things - including a language! - so long as it is easy and hurdle-less enough for them to do so
<gchristensen>
right
<joepie91[m]>
the problem isn't that Nix requires learning a language, rather that it's unreasonably difficult to do so
<gchristensen>
a language reference, for example, would be awesome
<joepie91[m]>
and not because the language itself is complicated, because it isn't really
<joepie91[m]>
but because of things like lacking (or even incomplete!) documentation, lack of clarity on where the boundaries are between Nix and nixpkgs, lots of legacy hacks that go unexplained, etc.
<joepie91[m]>
gchristensen: we have one, I believe, but it is neither complete nor easy to understand
<joepie91[m]>
in the Nix manual
<joepie91[m]>
I recall it missing a bunch of operators, even
<gchristensen>
the need for an ", I believe" makes it disqualified IMO :P
<joepie91[m]>
I don't disagree :P
<gchristensen>
maybe something to work on for my zurihack project
<samueldr>
I really want the nix* manuals to be better inter-linked, and more importantly, be one page per chapter
<manveru>
basically something you can read in an afternoon and then aren't left wondering what parts of the language you missed
<manveru>
what makes this more complicated in the case of nix are hundreds of conventions like usage of mkDerivation that aren't part of the language
<samueldr>
(tangentially) we might also need "scribes", people that takes in texts in any formats and docbookifies them, for those cases where we have people wanting to document things, but daunted by docbook
<joepie91[m]>
manveru: right. my complaint there would be that there's no always-visible menu/ToC despite being a very long page :)
<joepie91[m]>
right
<samueldr>
(I would transcribe things to docbook for others)
<joepie91[m]>
samueldr: ie. editors? :P
<manveru>
samueldr: i thought we can use markdown now?
<samueldr>
manveru: can in the technical sense :)
<manveru>
i.e. all those *.section.md files
<samueldr>
manveru: preferred to be docbook still AFAIK
<manveru>
damn :(
<joepie91[m]>
but yeah, I agree, scribes/editors are useful, not just for format conversion but also for translating not-very-understandable knowledge into understandable knowledge
<joepie91[m]>
there's usually not a lot of overlap between 'people who understand a thing' and 'people who can explain a thing'
<samueldr>
manveru: and that's good, please continue with markdown :)
<samueldr>
manveru: imo, better having docs in markdown than no docs
<joepie91[m]>
(that is solvable in principle, because it's a matter of practice, but in the interim it's useful to have people who can do the translation)
<manveru>
i like reading them in a terminal, and docbook fails at that hard :|
<samueldr>
it fails how?
<samueldr>
do you read markdown raw in the terminal?
<manveru>
exactly
<samueldr>
(not doubting, trying to better understand)
<samueldr>
ah, and there's no "docbookcat" or similar
<manveru>
mostly because i can actually grep locally in my terminal
<manveru>
so... missing search topic again
<samueldr>
though, search is hard... nothing worse than a bad search engine
* samueldr
thinks about the logs search engine
<manveru>
github search is atrocious too
<samueldr>
it's using a textual thing index, but it loses the ability to search specific text strings like URLs :/
<manveru>
so i usually end up doing `rg 'someFoo ='` in the repo
<samueldr>
(I was talking about the logs search)
<joepie91[m]>
search is hard, but not /that/ hard :P
<joepie91[m]>
for text anyway
<joepie91[m]>
code is more difficult
<joepie91[m]>
samueldr: most production systems compensate for this by keeping two indexes
<joepie91[m]>
one with literal strings and one with normalized strings
<samueldr>
yeah, I think the dev is running it on MySQL, which has different indexes, while I run in PostgreSQL
<samueldr>
I mean, different indexes implemented in code
<joepie91[m]>
(or some variety thereof, like eg. only storing literal strings for URLs)
<samueldr>
and while public, and open source, it's not exactly "distributed"
<joepie91[m]>
literal indexes can still be efficiently searched so long as they are a prefix match
<joepie91[m]>
which is fine for a URL
<samueldr>
though, in this case, URL was maybe a misnomer, URL parts too are hard to find
<samueldr>
or code example :)
<joepie91[m]>
yeah, code is an issue
<joepie91[m]>
because conventional efficient search systems (except for literal matches) don't really deal with structured data
<samueldr>
yeah
<joepie91[m]>
and I'm not sure that there even are generalized search models for code
<joepie91[m]>
or other structured data
<joepie91[m]>
pretty sure that all the code search engines just roll a custom thing for each format
<samueldr>
though the nix* manuals are small enough that indexes for words, and literal search for everything else should be fine
<__monty__>
gchristensen: Which part specifically do you disagree with? That writing documentation for someone lacking your background knowledge is hard because you need to consciously seperate common background knowledge from your background knowledege?
<__monty__>
joepie91[m]: I'm not saying we need to just wait around for inexperienced people to improve the docs btw.
Jackneill has quit [Remote host closed the connection]
<__monty__>
Maybe we should tell people to try to get issue reports on the documentation when there are people with problems in #nixos.
<joepie91[m]>
that would be a good start, but only if accompanied by a baseline policy of treating all mis-/non-understandings as valid documentation bugs :)
<joepie91[m]>
(unless shown otherwise, ofc)
<__monty__>
It's just that I feel like we can't ask the people fielding tons of questions currently, like clever, srhb, gchristensen and others to break out their documentation repo and improve the docs with every question.
<joepie91[m]>
__monty__: the thing is, the people who answer a lot of questions are likely the only ones who both a) understand the subject matter and b) can explain it
<joepie91[m]>
this actually somewhat reminds me of the management problem that the entire book The Phoenix Project revolves around
<joepie91[m]>
if you're constantly running around putting out fires and never structurally addressing what's starting the fires, you will forever be putting out fires
<joepie91[m]>
as an example of how to address this, over the years in #Node.js I've seen a lot of the same questions, and so I've compiled gists over time with the answers
<__monty__>
The *solution* I had in mind to getting inexperienced people going through the docs and reporting issues is mentoring btw. That way beginners have someone to fall back on rather than get stuck and those mentors can collect and hopefully generalize problems, rather than taking the micro-approach of rewriting sentences.
<joepie91[m]>
that has reduced the work required for a lot of questions from "understand and answer the question" to "link the gist and it's probably in there"
<joepie91[m]>
mentoring can be effective, but is also a much bigger commitment
<joepie91[m]>
in terms of availability
<joepie91[m]>
if it can be pulled off, it would be a great approach -- but if it can't, then "piecemeal publish notes about questions you get asked" is a good incremental approach
<joepie91[m]>
(and the person eventually working those notes into the 'real' docs doesn't need to be the same person who wrote the notes)
<__monty__>
I'm not sure that's true. We effectively have a few core people mentoring all of #nixos. They just have to take on so many that they can't possibly *also* improve the docs. These are valuable people and we have to avoid burning them out.
<joepie91[m]>
sure, but the difference is that they can come and go as they please in #nixos and answer questions when they get around to it; whereas mentoring a particular person is a 'hard' commitment and means they need to essentially be continuously available to that person
<joepie91[m]>
it's not that it takes more time, it's that it gives the 'helper' less control over when and where that time is spent
<joepie91[m]>
and that might conflict with other commitments (which is actually precisely why I don't take on mentees personally for things)
<__monty__>
Hmm, maybe making {^_^} database of facts easier to search would help. People have already been putting knowledge into one of the bots. It's just that people like me, who want to help but don't know enough yet have to absord the existing factoids by osmosis.
<__monty__>
If I had an overview of all the factoids it'd be easier to show appropriate ones to newcomers.
<joepie91[m]>
that would help some as well
<__monty__>
Oh, I'm very much not implying real-time mentoring. More like email pace.
<joepie91[m]>
ah, right. I'm not sure if that's sufficient to keep beginners around though
<joepie91[m]>
we have the added handicap of the OS/distro being a crucial tool, and essentially incapacitating when something doesn't work
<joepie91[m]>
so it's non-trivial to just 'set aside' an issue like you might with many other technical things
<manveru>
where are the facts stored atm?
<manveru>
i'd like to make a little page for them for easier discovery :)
<{^_^}>
import-from-derivation (IFD) is when you evaluate nix from a derivation result, for example `import (pkgs.writeText "n" "1 + 1")` will evaluate to 2. This is sometimes problematic because it requires evaluating some, building some, and then evaluating the build result.
<infinisil>
,help
<{^_^}>
Use `,` to list all commands, `,foo = Foo!` to define foo as "Foo!", `,foo =` to undefine it, `,foo` to output "Foo!", `,foo somebody` to send "Foo!" to the nick somebody
<infinisil>
joepie91[m]: Sounds good, feel free to replace it
<__monty__>
tilpner: Yes, infinisil said, that's still not very discoverable though. And I'm talking about searching the definitions and finding the keyword, not the other way around.
<__monty__>
sphalerite: And keep that up-to-date? :"(
<infinisil>
Actually I've thought of this before: It would be cool to implement most of nixbot's features in nix itself
<infinisil>
And this commands listing could be represented as an attribute set
<infinisil>
In the nix repl part
<infinisil>
So you could do
<infinisil>
> commands.tofu
<{^_^}>
undefined variable 'commands' at (string):255:1
drakonis has quit [Quit: WeeChat 2.5]
<infinisil>
And then you could text search with a nix function
<__monty__>
Could be cool. Doesn't solve the discoverability issue though.
<infinisil>
How would you solve this issue?
<__monty__>
I don't know. Advertize in the topic? Have {^_^} occasionally mention it along a factoid?
<infinisil>
Ah yeah that's an idea
<__monty__>
Hmm, explainshell.com doesn't know about ${V1:-V2}?
<joepie91[m]>
__monty__: because "how to ask smart questions" is confrontational and condescending, and that's generally not the tone you want to set in a conversation
<joepie91[m]>
unnecessarily confrontational and condescending, specifically
<joepie91[m]>
the new link covers the same subject matter, but in a far less confrontational manner
<joepie91[m]>
(that's actually precisely why that article exists, as explained therein)
drakonis has joined #nixos-chat
drakonis_ has quit [Ping timeout: 248 seconds]
<__monty__>
joepie91[m]: The new link has less information. And people don't have to read what they don't like. The people that are prepared to ignore the tone and get through the content can actually learn something more.
<__monty__>
Feel free to say "There's also this more abrassive article: ..."
<joepie91[m]>
__monty__: adding an extra link doesn't make it more justifiable to send people towards a condescending article.
<joepie91[m]>
and people don't "ignore the tone", because that is not how humans work.
<__monty__>
So my experience learning from it is invalid because ESR's not nice?
<joepie91[m]>
I said no such thing.
<infinisil>
I have to agree that smart questions has much more information
<infinisil>
Linking both sounds good too
<__monty__>
Well you're repeating the same thing "It's not nice." as a reason not to include it. Even after I said I'd be ok with a banner warning sensitive readers.
drakonis has quit [Ping timeout: 248 seconds]
<joepie91[m]>
oh, I agree that it has more information
<joepie91[m]>
that just doesn't automatically make it a better (or even a good) option
<joepie91[m]>
__monty__: that's because you're trying to negotiate unpleasantness, which is a hobby I've tired of over the past several years with more and more people trying to find excuses and justifications for being an asshole under the guise of 'facts' and 'information' and 'education' (and surprise surprise, it basically never has a desirable effect on a community)
<__monty__>
People don't have a right not to be offended imo btw.
<joepie91[m]>
if I have a problem with people being pointed at something because it's unnecessarily confrontational, that problem doesn't magically go away because it has a different prefix, because you are still pointing people at it
<joepie91[m]>
__monty__: that is 100% irrelevant to the discussion,
<joepie91[m]>
what matters here is what kind of behaviour we want to encourage and tolerate as a community.
<joepie91[m]>
"rights" don't come into it.
<joepie91[m]>
and I personally certainly object to being unpleasant towards people unless there's a good reason why it can't be done otherwise.
<joepie91[m]>
sometimes that good reason exists, most of the time it doesn't.
<__monty__>
Linking to ESR is not equal to telling people to behave like him. *Especially* if the factoid says "THIS IS ABRASIVE: link."
<joepie91[m]>
which makes an article like this unsuitable for a factoid (given that factoids are meant for the common cases)
<__monty__>
That's like two fallacies in one argument if you think about it.
<joepie91[m]>
that, again, is 100% irrelevant to the discussion - I claimed no such thing.
<samueldr>
isn't it already linked from the mikeash site?
<joepie91[m]>
you keep bringing in things that have nothing to do with my point.
<joepie91[m]>
when you link new people to confrontational and condescending articles, you filter them; only those who think that such an attitude is okay will stick around, and the ones who don't like it will leave.
<__monty__>
People are not allowed to ignore context, like a warning.
<joepie91[m]>
this is different when it's done in isolated cases, but again, we're talking about factoids here, which are for the common case
<joepie91[m]>
which means that pointing people at articles like this, will filter for people who think that ESR's attitude is fine.
<joepie91[m]>
which is certainly not what I want this community to consist of.
<joepie91[m]>
can't speak for others, of course.
<sphalerite>
joepie91[m]: I'm not sure that __monty__ sees a problem with thinking that ESR's attitude is fine ;)
<samueldr>
people are not allowed to ignore context, like setting a standard for reasonable discourse
<__monty__>
I'm a person who doesn't particularly like ESR's attitude. I also admit that he *does* have good information in some of his essays. I disagree that censoring good information just because the author is arrogant and abrasive is ok.
<sphalerite>
it's not censoring
<sphalerite>
it's just not linking to it
<sphalerite>
not talking about something is something completely different from censoring it.
<__monty__>
The link was there, now it's not, how is that not censoring it?
<samueldr>
picking *one* link is needed, if you send a soup of multiple guides for "how to ask a question" it's going to end up overwhelming
<__monty__>
Note that I'm not saying it needs to be *endorsed* just that it shouldn't be boycotted either.
<__monty__>
samueldr: That's why I said the new link should've gone under "getting-answers".
<joepie91[m]>
samueldr: not to mention that it's difficult to even get people to read beyond the first section of either article
<joepie91[m]>
(which also kind of negates the "more information" point)
<infinisil>
Yeah sounds good actually, ,smart-questions already hints that the user made a stupid question, which fits esr's article. getting-answers fits more to the other article
<__monty__>
I'm clearly representing a minority opinion here so I'm accepting whatever happens.
<__monty__>
infinisil: That's exactly what I meant.
<joepie91[m]>
infinisil: both articles address the *exact* same scenario.
<joepie91[m]>
just with a different attitude.
<joepie91[m]>
infinisil: which means that putting each article under its own factoid will just translate to "people either get a condescending response or a helpful response depending on who's talking"
<joepie91[m]>
it seems like "skewing towards the helpful response" is the more desirable option here.
<joepie91[m]>
seems to me *
<samueldr>
"be nice"
<infinisil>
Man, you all make good arguments, I'm conflicted!
<samueldr>
that's how I end up trying to write everything
<samueldr>
sometimes I'm not nice, most of the time I don't send the message unless it's warranted
<__monty__>
What I would do is ",getting-answers = summary+link, more abrasive take at ,smart-questions." ",smart-questions = There's decent information here but it *is* abrasive: link."
<joepie91[m]>
that doesn't actually solve any of the above issues.
<joepie91[m]>
(it's also... interesting how in your proposal one links to the other, but the inverse is not true.)
<__monty__>
joepie91[m]: It does solve your remark that it's hard to get people to even read part of either resource. Though I don't understand why adding a link no one, according to you, is gonna click anyway is such a problem.
<joepie91[m]>
once again, I said no such thing.
<joepie91[m]>
you really need to stop misrepresenting my points.
<__monty__>
This hides the second link behind an explicit query people would have to issue. So it already selects for people willing to put in effort.
<joepie91[m]>
that's like 3 times in a single discussion
<__monty__>
The inverse is not true because smart-questions isn't supposed to ever be used first.
<joepie91[m]>
__monty__: no, it doesn't, because "infinisil: which means that putting each article under its own factoid will just translate to "people either get a condescending response or a helpful response depending on who's talking""
<joepie91[m]>
yet it will be.
<__monty__>
joepie91[m]: I'll try to find the bit I interpreted that way, hang on please.
<joepie91[m]>
because there are going to be people who argue like you just did, that smart-questions "contains more information", and conclude from that that clearly it is the better option to link
<__monty__>
You seem to be excluding the possibility to manually paste an url or mention a googleable title.
<infinisil>
One thing I like about smart-questions is how it gets the point across that if you'd be wasting people's time if you make them answer stupid questions
<infinisil>
And that people who answer questions are sacrificing their free time for other people's sake
<infinisil>
With getting-answers, it's more on the side of "Don't waste your own time"
<__monty__>
18:38 < joepie91[m]> samueldr: not to mention that it's difficult to even get people to read beyond the first section of either article
<joepie91[m]>
grrr.... dark themes in Firefox...
<joepie91[m]>
__monty__: no, but people optimize for the common path, and so will more likely use a factoid than paste a URL
<samueldr>
joepie91[m]: ?
<joepie91[m]>
hence 'skewing towards'
<samueldr>
"grr" dark themes why?
<joepie91[m]>
samueldr: input fields are broken, styling-wise, as per usual
<joepie91[m]>
black text on black background
<joepie91[m]>
you'd think they'd fix this after 10 years
<__monty__>
This is the bit I phrased as "It does solve your remark that it's hard to get people..."
<samueldr>
joepie91[m]: right, wanted to know if there was another new issue than "using system styling for form inputs in html was a mistake" :)
<joepie91[m]>
infinisil: that is very much intentional; the "you are wasting people's time" is confrontational and often not needed
<joepie91[m]>
it tends to sour the discussion whenever applied
<joepie91[m]>
sometimes it is necessary, but usually not
<joepie91[m]>
__monty__: ah. I was referring to "Though I don't understand why adding a link no one, according to you, is gonna click anyway is such a problem."
<joepie91[m]>
with the "I said no such thing"
<__monty__>
joepie91[m]: Well that part was originally by samueldr but you seemed to agree.
<joepie91[m]>
I didn't see samueldr claim that either, but no, I am not making that claim
<samueldr>
what did I claim?
<joepie91[m]>
my problem is that people will click it and then get soured on the discussion by the attitude on display there.
<samueldr>
I think I meant "given a fresh arrival, please don't dump a huge list of required reading" or thereabout
<joepie91[m]>
for Breeze, you need that second option
<joepie91[m]>
__monty__: I still haven't seen a reason to link it in a factoid in the first place
<__monty__>
The reason is it has *better* information. And imo the extra information outweighs the attitude.
<joepie91[m]>
__monty__: as samueldr(?) pointed out, it is already referenced in getting-answers.
<joepie91[m]>
so that problem is solved, as far as I'm concerned.
cjpbirkbeck has joined #nixos-chat
<__monty__>
joepie91[m]: I have no reason to assume this will remain the case. It's also harder to explicitly point to for no reason.
<joepie91[m]>
oh, it absolutely has a reason, just one you don't seem to share :)
<joepie91[m]>
namely, making it less likely for people to respond with confrontational, condescending articles
<joepie91[m]>
which is the point, not a bug
<__monty__>
As in "Maybe read ,getting-answers and I think you'd benefit from ,smart-questions too." not "Go read ,smart-questions."
<joepie91[m]>
people can decide that for themselves upon reading getting-answers, no?
<joepie91[m]>
the reference is there.
<__monty__>
That makes it worse not better.
<__monty__>
Why can mikeash link to it but we can't? You can put the exact same paragraph shielding the link in the factoid if you want.
<joepie91[m]>
I've already answered that: to discourage explicitly referencing it.
<joepie91[m]>
and as this discussion progresses, I can't help but feel that your objective here is "keep the ability to point people at a confrontational article"
<__monty__>
Maybe because that's exactly the point...
<joepie91[m]>
because your arguments don't make sense in any other context that I can see
<joepie91[m]>
and well, like I said, that is precisely the kind of behaviour that I want to discourage.
<joepie91[m]>
because that filters for the wrong people, attitude-wise.
<__monty__>
And I'm saying you have no right doing so. It's very patronizing. You're assuming both that 1) people can't deal with unfriendly writing and 2) that me and others don't have the intelligence necessary to decide when it's appropriate to link to.
<__monty__>
I've wasted enough words on this though. I'd be grateful if we could drop it.
<joepie91[m]>
this has absolutely nothing to do with 'intelligence' or 'what people can deal with', and everything with what kind of community we want to foster here.
<joepie91[m]>
you are correct that I am not in a position to authority to decide this; nobody is, that is why I am making public arguments, because this sort of thing is something that will ultimately be decided through informal consensus
<joepie91[m]>
position of authority*
<joepie91[m]>
but it is absolutely an important topic to discuss.
<joepie91[m]>
and merely that a human can deal with a particular kind of abuse, doesn't warrant inflicting that sort of abuse.
<joepie91[m]>
for reasons that I hopefully don't need to explain...
<__monty__>
Oh, one more suggestion ,getting-answered as in my last, ",smart-questions = This article is unnecessarily abrasive, only read this if you can ignore the tone ,smart-questions-random-string-nobody-can-remember" ",smart-questions-nobody-can-remember= WARNING ABRASIVE: link."
<joepie91[m]>
this is all still negotiating unpleasantness.
<joepie91[m]>
at that point, you can just look for the URL and paste it yourself.
<__monty__>
I disagree that the essay is abusive. Let's not exaggerate here.
<joepie91[m]>
I am not exaggerating.
<joepie91[m]>
when something is considerably harsher on people than is warranted given the situation, I consider that abusive.
<joepie91[m]>
the essay meets that criterium.
drakonis has joined #nixos-chat
<drakonis>
i'm going to butt into the conversation real quick, ESR's essay is actually fairly confrontational, and how that is measured, varies across reader to reader
<drakonis>
the name of the essay already throws shade at the reader
<drakonis>
now, let's get to the root of the topic, how are we going to draft new documentation?
<__monty__>
My reaction to the essay's title was "Huh, *am* I asking bad questions? Let's find out! Hmm, some good points. Now I'm better at asking questions, yay!"
<drakonis>
well yeah, but that's you
<drakonis>
there are folks that won't take so kindly to being called dumb when they're linked to it
<__monty__>
Sadly those are exactly the ones that should be reading smart questions and not getting answers : /
<drakonis>
now, if we're going to write new docs, let's try to start over, to avoid the lava layer problem
<drakonis>
the pills are nice and fun but they're about to go stale when 19.10 and beyond releases
<joepie91[m]>
Drakonis: I'd say that the main ingredients we need are a) a good idea of exactly where the issues of understanding lie, b) some degree of reliable access by documentation writers to people who can clarify unclear things (which is likely going to be a very small group for some things), c) people who can actually write good documentation :P
<obadz>
oh cool, gchristensen
<__monty__>
Drakonis: A complete rewrite requires a lot of effort though. So it risks stalling.
<joepie91[m]>
part of the reason for the papercut thread is to be an ingredient A (though not complete), trying to capture the unreported annoyances that people have, including documentation issues
<joepie91[m]>
but we definitely need more coverage, eg. by having common IRC helpers take notes on common questions and issues, and looking at docs issues in repos
<joepie91[m]>
possibly even a separate place to report docs issues, because right now they seem to be kinda drowning in broken package issues
<drakonis>
it'll soon be a year since that post and not much has changed in the docs front
<joepie91[m]>
I did address some specifics of that earlier, referring also to how the Matrix project does it; a docs repo, with docs issues, where the baseline is "every documentation issue or confusion is a valid issue, unless shown otherwise", and issues are considered contributions -- the barrier to filing an issue there is super low because you know that you won't be spending an hour defending your issue
<__monty__>
infinisil: It might actually help if there were stats on how often factoids are used actually. Then we can prioritize documentation for the things that are linked most often.
<joepie91[m]>
that would really help in inventorying outstanding docs issues here
<drakonis>
there's also a book writer on twitter, i cannot recall what's his name there
<drakonis>
but he wanted to write a book but he found the docs to be impenetable
<joepie91[m]>
heh, right
<drakonis>
impenetrable
<samueldr>
joepie91[m]: (two parter question) how would you sync the documentation with the of the nixpkgs repository?
<joepie91[m]>
Drakonis: similarly, I've wanted to write better docs, but I don't have access to the people with the answers, at least not reliably
<samueldr>
joepie91[m]: (second part) is it absolutely required to be synced up?
<joepie91[m]>
and I don't understand it well enough myself, so...
<samueldr>
joepie91[m]: how you sync up the docs with the nixpkgs revision?
<samueldr>
so that you have "the docs for 19.03"
<drakonis>
you might want to ring him up and ask about his issues
<samueldr>
but at the same time
<samueldr>
there is already an issue where docs updates don't go to nixos.org until the new release releases
<samueldr>
or they get backported
<samueldr>
so it might be a better idea to instead work on versioning *in-place* the documentation
<joepie91[m]>
samueldr: I'd say that in 99% of cases that wouldn't be necessary, and might even be a pipedream, given that the docs aren't even anywhere near complete *right now*
<samueldr>
joepie91[m]: yeah, the question wasn't a "real question" but a conversation seeder :)
<joepie91[m]>
samueldr: we have a very short support period for superseded releases, so- yeah, that
<samueldr>
the documentation, anyway, already has parts about earlier versions, I think, and differences between them
<joepie91[m]>
just have documentation for "the current version", and during overlap periods, have marked blocks that only apply to specific versions
<joepie91[m]>
and clearly indicate as such
<joepie91[m]>
bonus: makes it easier for people to spot the new stuff
<joepie91[m]>
right, but not in a consistent format
<joepie91[m]>
unless you mean the changelog
<samueldr>
right
<samueldr>
having them out of the repository could help in that sense, documentation almost is "trapped" inside of the release cycle
<joepie91[m]>
right
<joepie91[m]>
yeah, that's no good
<samueldr>
though, it's not like there isn't value in having the documentation for the current revisions inside the repo :/
<joepie91[m]>
in theory, sure
<samueldr>
you have a holistic self
<joepie91[m]>
in practice, docs don't match the repo anyway, really
<samueldr>
yeah
<joepie91[m]>
due to their incompleteness
<joepie91[m]>
so I think this is a reaaaaaally low-value objective
<joepie91[m]>
maybe worth considering once we have consistently complete docs, but no earlier than that, imo
<drakonis>
the wiki covers things the docs do not
<__monty__>
Wouldn't a submodule or subtree be fine for including the docs in the repo?
<samueldr>
submodules are terrible to work with in my experience :/
<joepie91[m]>
yeah, can't say that'd make me happy :P
<samueldr>
though, in reality I guess nixpkgs will have a derivation for a particular revision of the docs
<samueldr>
and that's what will be "shipped"
<drakonis>
do a docs pass for every release
<samueldr>
e.g. the documentation available on the installer
<drakonis>
after refreshing everything
<samueldr>
right, Drakonis, up for that?
<drakonis>
yes
<samueldr>
then please do :)
<joepie91[m]>
Drakonis: 'docs pass'?
<drakonis>
that means going through the documentation
<drakonis>
rather, it would be something best done after the new documentation
<drakonis>
i have to get my thoughts in order, i just woke up
<samueldr>
[13:30:52] <joepie91[m]> Drakonis: similarly, I've wanted to write better docs, but I don't have access to the people with the answers, at least not reliably
<samueldr>
^ what can *I* (and *we*) do to help you?
<drakonis>
also the first step towards making better docs is to have a good reference for the nix language, it is currently spread between several sources
<drakonis>
the manual for nix refers to the package manager but not the language
<drakonis>
nixpkgs refers to the repository itself
<samueldr>
Drakonis: the manual for nix refers to the language, chapter 15 (currently)
<joepie91[m]>
samueldr: well, realistically, to make writing docs viable for me within my time constraints, I need uninterrupted access for blocks of time to somebody who can answer basically any question on a given topic/piece
<samueldr>
though imo that section is so deep it's as good as invisible :(
<joepie91[m]>
samueldr: the feedback loop needs to be real-time, basically, rather than waiting a day for every question
<drakonis>
i skimmed the ToC and it felt invisible
<samueldr>
joepie91[m]: is it something that you can prepare a batch of questions for a topic, so it's possible to then split into "oh, $contributor knows THAT* and then schedule a meetup for a part of the questions?
<samueldr>
because I feel there's no *one* persone to rule them all
<joepie91[m]>
samueldr: I can prepare a list of topics, but I can't prepare a list of questions, because each question is likely to be dependent on the previous
<joepie91[m]>
my modus operandi is basically to dig down into a topic gradually
<joepie91[m]>
based on the answers I get
<samueldr>
hm :/
<joepie91[m]>
it is very effective in fishing out all the obscure details, but doesn't work without real-time access and improv :)
<samueldr>
then we need you someone that knows enough about a bunch of things to at least get most of it right, and enough to abstract away for further deeper dives
<joepie91[m]>
right, either that, or just know which person has the details on a specific topic
<joepie91[m]>
and schedule a block of time with said person when planning to write about a specific topic
<joepie91[m]>
but that does depend on their availability
<joepie91[m]>
and the problem mentioned earlier still applies -- most of the people who have the answers in Nix-land, are too busy to hand them out
<colemickens>
Drakonis, do you mean me? I tied to give you a tip last night but I didn't mention your name
<colemickens>
is it still allowUnfree that's giving you issues?
<drakonis>
yes i do mean you
<drakonis>
i had to enable impure mode for it to work
<drakonis>
flakes nix seems to default to running everything on pure now?
<colemickens>
hm, I'm not sure which mode I'm building in. I think I'd tried it with --pure, but I don't see that in my script currently
<pie__>
total sidenote, joepie91[m], coworker reimplemented something i spent two months nixing on and making fancy in a few hours in bash (albeit with a lot less functionality), and its sufficient for the job
<drakonis>
allowUnfree is separate from rebuilding though
<__monty__>
pie__: Release early, release often ; )
<pie__>
__monty__, well i did do that kind of, thats not the problem :V
<pie__>
just put too much effort into something that maybe i shouldnt have
<drakonis>
colemickens, i mostly feel dumb because i didn't know that was possible until you linked your repo yesterday
<colemickens>
(I'm not sure I understand well enough what state you're at the moment in to really advise, sorry - sounds like it's working but you want it working in pure mode?)
<pie__>
joepie91[m], man youve given me a lot of scroll to read: P
<__monty__>
joepie91[m]: Maybe we should start an org/repo or a forum or a mailing list, just so we can get people together that want to commit some time to improving the docs. Then we can discuss next steps and hopefully be a first point of contact for anyone who wants to report problems with the docs but doesn't have the knowledge to fix them?
<drakonis>
my state is that i can only run nonfree software with nix run on flakes if i use the --impure flag, otherwise it does not look up, it seems to default to always running on pure mode now
<drakonis>
the shell script used for rebuilding hasn't been updated for flakes, so i was going to wait it out, until you linked me your repo, i didn't know that was a thing
<__monty__>
That's weird though. What does free-ness have to do with purity?
<drakonis>
because it has to be set on ~/.config/nixpkgs/config.nix
<drakonis>
and on pure mode it doesn't look at mutable directories
<drakonis>
i figured it out when i saw that in edolstra's nix-warez repository, the packages had commented licenses
<drakonis>
and there's also the flakes docs i suppose
<drakonis>
my logic is kinda weird.
<joepie91[m]>
__monty__: I agree
<joepie91[m]>
__monty__: this sounds like another WG in the making :)
<joepie91[m]>
it does the same thing as Discourse, one single 'homepage'
<joepie91[m]>
with all posts from all categories
<joepie91[m]>
you can filter down on the categories, but by default you see everything
<joepie91[m]>
traditional forum software usually just shows you the index of subforums and maybe the last 5 posts, on the homepage
<joepie91[m]>
imo the single-feed model works waaaay better for keeping forums alive
<drakonis>
i don't know, there's forums with dozens of threads that get updated on a daily nais
<__monty__>
Isn't it easy to forget to/miss-tag posts?
<drakonis>
per subforum
<drakonis>
daily basis rather
<joepie91[m]>
__monty__: there's a category picker on the new thread page
<joepie91[m]>
Drakonis: ?
<joepie91[m]>
not sure what you are trying to say with that :P
<__monty__>
I'm partial to the subforum approach tbh. I visit some really old really quiet forums and it's just nice that it's so simple to find the old stuff and also have an overview of new stuff.
<__monty__>
But nixos has a discourse so it's a moot point.
<drakonis>
discourse works fine for small communities
<drakonis>
i'm trying to say that discourse doesnt work well when you have lots of people
<__monty__>
Cross that bridge when we get to it?
<drakonis>
eh
<joepie91[m]>
don't know about Discourse, but Vanilla has worked very well for LowEndTalk
<joepie91[m]>
and that is (or well, was) definitely a highly-trafficked site
<samueldr>
how does "discourse doesnt work well when you have lots of people"?
<samueldr>
I think it was designed for that in mind
<samueldr>
with learnings from SO
<joepie91[m]>
anyway, this is a tangent :)
<joepie91[m]>
we need a place to discuss docs, basically
<joepie91[m]>
a docs repo would be a good place to start, imo
<drakonis>
yes
<drakonis>
samueldr, jeff atwood went to ask something awful about advice on forums software and he got long form effort posts which he promptly disregarded
<drakonis>
:| he also went "i made this really popular website, therefore my opinions are more important than yours"
<drakonis>
he also went "apple is right, do what apple does, don't give anyone any option at all"
<drakonis>
how are we going to structure the docs anyways?
<joepie91[m]>
Drakonis: so I would argue for a *single* documentation set for Nix, nixpkgs, NixOS -- but this requires some sort of way to mark particular sections of the documentation as being specific to one of those
<joepie91[m]>
but yeah, I'd be largely okay with asciidoc, it's just that I can't really find anything about extensibility points
<joepie91[m]>
and I do think that we will need that, if we want to have a chance at really making the documentation /good/
<samueldr>
yeah, it's likely we do
<joepie91[m]>
the reference implementation of asciidoctor is in Ruby I believe, and I don't speak Ruby, so I can't commit to extending it myself either
<joepie91[m]>
(whereas I can commit to rolling custom components for MDX usage, for example)
<joepie91[m]>
my main complaints about MDX are 1) invocation syntax is JSX, ie. XML, which will likely require snippets on the part of writers to use efficiently, and 2) nested markdown does not work well yet
<joepie91[m]>
point 2 is fixable, at least in theory
<joepie91[m]>
otherwise MDX does tick all the boxes for me
<drakonis>
then there's his dotfiles from before he started running nix
<andi->
Should call my system ANDI OS!!11 also thousands of lines :)
<drakonis>
seems kind of boring and not notable, nothing to gripe about
<drakonis>
happens to every distribution
<andi->
If it spreads the word of the holy Nixos way.. Why not
<drakonis>
he wrote a docker service for some reason?
<drakonis>
there's a bunch of choices that don't make a whole lot of sense
<infinisil>
andi-: Yeah, my config is about 6000 lines of code now too, I'll call it infinOS
<infinisil>
I guess this guy did create his own gtk and vim themes though, and he's setting them in the repo
<andi->
It's all right by my standards.. :)
<drakonis>
i'm not sure why he has a bunch of services for toggling features
<drakonis>
when you can just add them to the config and tweak it all yourself?
<drakonis>
actually, these arent even enabled
<joepie91[m]>
Drakonis: the problem isn't converting formats, the problem is what format to use for authoring :)
<infinisil>
Yeah screw that, and screw everybody who thinks everything that looks a bit different is a separate OS
<drakonis>
ah i see, i can't opine on it
<drakonis>
can't suggest anything
<drakonis>
this guy is a serial unixporn poster apparently?
<drakonis>
he keeps changing the background
<drakonis>
so if anyone looks into that repository, its likely that it will feature a different setup
<drakonis>
i honestly don't see why he's writing his setup like that, its such a huge mess
<manveru>
nixos is like perfect for ricing :)
<drakonis>
i'm surprised the ricers have not flocked here
<__monty__>
joepie91[m]: Maybe you can write in asciibook and pandoc *to* docbook?
<manveru>
and if people can call stuff like kubuntu or xubuntu "distro"... then nixos is a distro for making distros indeed :D
<drakonis>
__monty__, why tho
<drakonis>
gentoo is supposed to be a metadistro...
<joepie91[m]>
__monty__: that still doesn't solve the problem of what authoring format to use
<__monty__>
Drakonis: Because the current format is docbook and joepie91[m] wants to write in asciidoc?
<joepie91[m]>
nono
<joepie91[m]>
I'm saying that asciidoc /could/ be an acceptable option, if there are extension points, but I have not been able to find them
<joepie91[m]>
otherwise, MDX may be a better option (or whatever other format people can come up with that is suitable for authoring and has extension points)
<samueldr>
not even need to pandoc, asciidoc(tor) says it outputs to docbook directly if needed
<joepie91[m]>
so right now, I'm leaning towards MDX, unless somebody can show me extensibility in asciidoc :P
<joepie91[m]>
also, wasn't asciidoc basically designed to be directly mappable to docbook
<samueldr>
I had a wee look see and extensibility in asciidoc looked... not that ergonomic
<__monty__>
My vote is definitely in favor of reST over MDX.
<drakonis>
jfc i was closing my tabs and accidentally saw that the starlight guy has his stateversion set to unstable with #did you read the comment?
<drakonis>
he certainly didn't read the comment
pie__ has joined #nixos-chat
<infinisil>
Lol
<drakonis>
i have made that mistake once
<joepie91[m]>
Drakonis: wow, somebody managed to overlook the second comment
<joepie91[m]>
impressive
<joepie91[m]>
it's a really well-placed comment :)
Guanin has joined #nixos-chat
<joepie91[m]>
samueldr: can you link me to the extensibility stuff?
<samueldr>
I didn't actually find docs, but looked at one of their extension gem
<samueldr>
it might have better ergonomics for external users
<samueldr>
joepie91[m]: ^
<pie__>
spent 3 hours staring at a missing unlist() call, if you want to shoot yourself in the foot, choose R
<pie__>
the pipes R cool tho
<joepie91[m]>
my foot is already sufficiently holey, thank you very much