gchristensen changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 19.09 is released! https://discourse.nixos.org/t/nixos-19-09-release/4306 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | https://r13y.com | 19.09 RMs: disasm, sphalerite; 20.03: worldofpeace, disasm | https://logs.nix.samueldr.com/nixos-dev
<qyliss> I don't see how we're going to get to that, though.
<infinisil> So I hope if we move docs closer to the code somehow this should improve
<qyliss> +1 to that
<qyliss> But I really don't think format is going to make a difference
<qyliss> If somebody's going to write several paragraphs of documentation, checking how to insert a link is not going to be the blocker.
<gchristensen> glad we agree, let's stay with docbook
<qyliss> Docbook is hugely inconvienient to write even for normal prose, so I don't think it counts.
<qyliss> But nothing else under consideration has that property.
<qyliss> For all of them, you can write them as if they were text almost entirely
<gchristensen> I thought you didn't think the format was going to make a difference
<infinisil> Hehe yes qyliss ^
<qyliss> The _non-docbook_ format
<gchristensen> ahh... I got it. Troff!
<infinisil> Yeah I'd guess as long as it looks simple to write, people wanting to write docs won't be repelled from it
<qyliss> You know what I mean. I'm not here to be trolled.
qyliss has left #nixos-dev ["WeeChat 2.6"]
* gchristensen PM's to appologize
<domenkozar[m]> this is good
<domenkozar[m]> it's going to happen!
<infinisil> \o/
<simpson> I wonder whether the docs will get better, or just more.
<infinisil> Let's scrap all of them and start from scratch!
<infinisil> No need for conversion tools either then :D
<infinisil> And no more outdated docs either (at least for the time)
<domenkozar[m]> it's going to give a bunch of people energy to fix stuff
<domenkozar[m]> so given similar events in the past, I'm quite positive
<infinisil> Oh man, github already starts collapsing the comment thread of rfcs#64
<{^_^}> https://github.com/NixOS/rfcs/pull/64 (by Infinisil, 5 days ago, open): [RFC 0064] New Documentation Format for nixpkgs and NixOS
<gchristensen> great
<infinisil> I hate that
<domenkozar[m]> needs more entropy
lovesegfault has joined #nixos-dev
<gchristensen> say, didn't the RFC shepherd team rotate? (cc worldofpeace)
evanjs has quit [Quit: ZNC 1.7.4 - https://znc.in]
evanjs has joined #nixos-dev
lovesegfault has quit [Quit: WeeChat 2.7]
colemickens_ has joined #nixos-dev
zarel has quit [Ping timeout: 268 seconds]
zarel has joined #nixos-dev
ris has quit [Ping timeout: 258 seconds]
ixxie has quit [Ping timeout: 265 seconds]
colemickens_ has quit [Quit: Connection closed for inactivity]
bhipple has joined #nixos-dev
lovesegfault has joined #nixos-dev
zarel_ has joined #nixos-dev
zarel has quit [Ping timeout: 265 seconds]
bgamari has quit [Quit: ZNC 1.7.3 - https://znc.in]
bgamari has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.6]
noonien has quit [Quit: Connection closed for inactivity]
bhipple has quit [Remote host closed the connection]
kenjis has joined #nixos-dev
<worldofpeace> u mean Steering team gchristensen, or maybe that's the Merge bot RFC (which currently lacks a leader)?
lovesegfault has quit [Quit: WeeChat 2.7]
lovesegfault has joined #nixos-dev
lovesegfault has quit [Ping timeout: 246 seconds]
kenjis has quit [Remote host closed the connection]
lovesegfault has joined #nixos-dev
lovesegfault has quit [Ping timeout: 248 seconds]
lovesegfault has joined #nixos-dev
<jtojnar> should oxij be cc'd for the tor-browser removal
<jtojnar> ?
<jtojnar> oh, it was merged already, GitHub just did not update the new tabs in the last ten hours
<jtojnar> s/tabs/comments in the opened tab/
lovesegfault has quit [Ping timeout: 260 seconds]
<flokli> jtojnar: yeah, I forgot to highlight.
<flokli> but there was a broad consensus in #nixos-security that the current state causes a lot of harm and maintainability pain
<flokli> I added a comment to the issue.
<jtojnar> yeah, but it is still a good idea to cc all stakeholders
<flokli> yes, you're right.
<flokli> whis is also why I assigned andi- to https://github.com/NixOS/nixpkgs/pull/77507 ;-)
<{^_^}> #77507 (by oxij, 18 minutes ago, open): firefoxPackages.tor-browser: 8.5.6 -> 9.0.4
ris has joined #nixos-dev
Jackneilll has joined #nixos-dev
<worldofpeace> Oh this finally happened 👍️
<worldofpeace> Jan Tojnar: yes yes yes please, all stakeholders should be notified on every ticket
Jackneilll has quit [Quit: Leaving]
__monty__ has joined #nixos-dev
qyliss has joined #nixos-dev
<gchristensen> worldofpeace: yeah steering oops
<worldofpeace> gchristensen: yeah it rotated, I'm on it now. But I've shamelessly missed every meeting up to now 🤣
<gchristensen> yikes, that isn't good :x that team needs to be rock solid
<gchristensen> I'm sure it will become that way, though :)
<gchristensen> probably just a rocky beginning
<gchristensen> cool, https://github.com/nixos/rfcs#members-of-the-rfc-steering-committee is out of date -- I'll update it unless someone beats me to it :)
<worldofpeace> It has been decided to have biweekly meetings, which will make it better. The time of said meeting is a bit skewed to London'ish time, hopefully that gets sorted
<worldofpeace> gchristensen: easy solution to that is link https://github.com/orgs/NixOS/teams/rfc-steering-committee
<worldofpeace> (if the team is public)
<qyliss> team links like that usually aren't IIRC
<qyliss> Indeed, they are not
<worldofpeace> The "Workflows and notes from Nix steering committee" just makes me think the team would be much easier. Somebody changed that first already
<gchristensen> right, I'm just thinking it'd be nice to have the list be in a version controlled spot so you can see when and how it changed easily, which you can't do with teams
<gchristensen> and since the change is not often, not much of an overhead
FRidh has joined #nixos-dev
zarel_ has quit [Ping timeout: 265 seconds]
zarel has joined #nixos-dev
<LnL> man, I wish I looked into this sooner https://git.io/Jvfss
<simpson> Nice.
<yorick> LnL: did libexpr moved to passing string_view instead of string&?
<LnL> not sure, I'm not very familiar with this part of the code
<yorick> I think string& is fine
<yorick> the other errors have it too
<LnL> ideally it would show the original code instead of it's representation, since that can look a bit strange
<LnL> but better than nothing
* LnL continues fighting with weird null errors
<domenkozar[m]> LnL++
<{^_^}> LnL's karma got increased to 19
kenjis has joined #nixos-dev
noonien has joined #nixos-dev
drakonis has joined #nixos-dev
<gchristensen> holy guacamole, LnL!
<tazjin> I'm building a package tree documenting tool now (as a demo for the RFC and to experiment with useful features) and the two formats I'm experimenting with are markdown & asciidoc. All links I can find for asciidoc lead me to the Ruby (:/) implementation being the only canonical one, but I've heard there's another one - any ideas?
<gchristensen> I think that is all there is
<tazjin> there's a former website for asciidoc (up to 2011), which eventually links through to a python version that is marked as deprecated: https://github.com/asciidoc/asciidoc
<tazjin> and that's all I can find
<gchristensen> drakonis: hey so your idea for metadat anad whatnot for nixpkgs for discoverability could even get a grant under NGI0 I think?
<tazjin> I think it would be useful for the RFC demos if we had a target output page (say one page for a NixOS module, one page for a language build infrastructure)
<drakonis> gchristensen: it definitely can.
<drakonis> https://nlnet.nl/discovery/ this one?
<__monty__> Probably having all the features people mention being important demonstrated is important, tazjin?
<tazjin> __monty__: people have mentioned every feature under the sun, spread out over various IRC logs, RFC comments and forum threads :|
<__monty__> Yeah, but not covering the features will mean these people will object to the demos.
<__monty__> Might also lead to bias in favor of a certain format. "Oh, this thing is easy in X, I'll put it in the reference demo."
<tazjin> is that really bias if X is a good feature?
<gchristensen> drakonis: yeah
<__monty__> tazjin: Yes because it makes X look good even though it doesn't support features a, b and c.
<gchristensen> who cares?
<gchristensen> that is the point of a PoC
<gchristensen> and the reason somebody invested in a format would be best suited to do a PoC
<__monty__> Well, if you're gonna use markdown to do the PoC you're gonna miss most features but it'll look the best because markdown is designed to look nice and simple in exchange for being featureful.
<tazjin> __monty__: I think extensibility should be a real criteria here actually, so if X doesn't have a, b and c one question should be "how hard is it to add them?"
<__monty__> Sure.
<tazjin> 15:38:05 <__monty__> Well, if you're gonna use markdown to do the PoC you're gonna miss most features <- citation needed :]
<__monty__> I'm just saying maybe we should figure out a subsection of the docs that includes most of the features people want.
<__monty__> I.e., I think one section's too few for example. Because interdocument links are one of the features people wanted.
<tazjin> I think the only format that doesn't support links natively is plain text
<__monty__> Markdown doesn't have them. Not sure about commonmark.
<tazjin> and I was just saying to gchristensen that I think we need to clear the format hurdle before we can move on to the interesting stuff, e.g. what should the docs layout be
<tazjin> I'm quite sure Markdown has links, I have written lots of links in Markdown
<__monty__> Urls, not links inside the same file or across some local files.
<tazjin> that is a function of your docs layout and serving system, not of the format
<tazjin> in fact I'd argue in the opposite direction
<tazjin> if links to your output are so hard to construct that you need special tooling support ... rip
<tazjin> because humans also construct links manually sometimes (or try to)
<tazjin> I suspect what you actually mean is "internal link validation at build time", which is not a big issue in any format
<__monty__> What? "Cf. the last section" <- Why shouldn't that be a link? Without having to go "OK, the rendered version's gonna have urls like /docs/ch1/sec12."
<__monty__> I'm talking about a very simple thing, like latex's \ref.
<tazjin> so you mean this? (written in gfm) https://www.irccloud.com/pastebin/sGxF8IFH/
<__monty__> Yeah, extension #1.
<tazjin> yeah of course there will be extensions
<tazjin> that's true for any format
<__monty__> I'm assuming it's not true for docbook?
<gchristensen> of course it is true for docbook
<gchristensen> docbook is the king of extensions
<gchristensen> there is no limit to the extensions you can do with docbook, because there is no limit to the structural tree parsing and manipulation steps you can do before passing it to the docbook-xsl formatting step
<__monty__> Extensions in the markdown sense or does it offer a way to "extend" the language you write docs in?
<gchristensen> you can do literally anything you want
<__monty__> You can process any format any way you want though.
<__monty__> Are we talking lisp-macro-like extensions?
<gchristensen> XML is basically S-Expressions yes
<gchristensen> (and XSLT is essentially a lisp)
<tazjin> jtojnar: not oob
<jtojnar> hmm, maybe we could run Nix parser in JS and link the options in codes at runtime
FRidh has quit [Quit: Konversation terminated!]
<tazjin> jtojnar: pls no
<gchristensen> there you go
<gchristensen> though you could do it with xslt
<jtojnar> I think I would even prefer writing Nix parser in JS to XSLT
<tazjin> I only just realised that the current manual barely has syntax highlighting
<gchristensen> jtojnar: well yeah, you could use ,jdwhat's parser in Rust and WASM your way to a JS parser :P
<qyliss> tazjin: the canonical one is written in Python I believe
<tazjin> qyliss: that's deprecated
<qyliss> oh, right
<gchristensen> tazjin: it was an intentionally chosen theme to be minimal and unobtrusive
<qyliss> then maybe everyone just moved to Asciidoctor
<tazjin> yeah asciidoctor is the official one (as per the info string on the old python repo)
<__monty__> Maybe antora is the second implementation now?
<jtojnar> there is also https://github.com/asciidoc/asciidoc-py3 but it is somewhat weird
<tazjin> jtojnar: I can't think of a syntax for links in code blocks that wouldn't be disruptive to reading the thing in plain text
<tazjin> I guess docbook just shoves a ton of XML into the snippets?
<__monty__> tazjin: That's one of these features that result in bias towards asciidoc I think : ) (They call it out specifically while I don't know of other formats supporting it.)
<jtojnar> tazjin can't we get away from plain text in 2020?
<tazjin> jtojnar: no, thanks
<tazjin> __monty__: what's their syntax for it?
<jtojnar> tazjin not a ton, just the regular elements
<qyliss> aanderse: what do you think I should do about #75782? Make my own PR? Merge it with jonringer's suggestions? Fold it into by bigger PR?
<{^_^}> https://github.com/NixOS/nixpkgs/pull/75782 (by peti, 3 weeks ago, open): Update mailman, postorius, and hyperkitty to their respective latest versions
<jtojnar> everything is a tree so why not manipulate it diretly as a tree?
<__monty__> tazjin: Can't find the site where I saw it rn. I remember something fancier than asciidoc.org and asciidoctor.org.
<tazjin> jtojnar: because I'd rather give people the ability to focus on writing docs than on thinking about tree manipulations
<{^_^}> asciidoc/asciidoc-py3#11 (by asciidoc3, 1 year ago, closed): Congratulations and a drop of bitterness
<tazjin> __monty__: https://antora.org/?
<jtojnar> tazjin well that can be hidden by a WYSIWYM editor
<jtojnar> I will need to check if http://www.nongnu.org/thotbook/ works
<tazjin> jtojnar: I'm not sure if adding even more barriers to entry by introducing a custom editor is sane, tbh
<gchristensen> jtojnar: not sure I'm keen on a project for documentation editors where their main home page is just an initial homepage from 19 years ago
<qyliss> Being able to make changes using the GitHub web UI is probably important.
<gchristensen> I meant to add a :P to the ond of that btw :)
<jtojnar> if it worked it could be an extra option, not suggesting it to be the official editor™
<jtojnar> not sure GitHub web UI is a good way to edit docs for anything but fixing typos
<qyliss> I don't think it is either, but drive-by-ers might.
<jtojnar> and Docbook should not prevent you from fixing typos
<gchristensen> it probably doesn't
<aanderse> qyliss: probably just poke @peti with a sharp stick :)
<qyliss> not sure I have any special powers in that regard
<aanderse> qyliss: was mostly just a FYI
<qyliss> Ah, right.
<aanderse> yeah i didn't necessarily think you should do anything
<jtojnar> I am volunteering for https://github.com/github/markup/issues/1314 if we get some response from GitHub
<{^_^}> github/markup#1314 (by jtojnar, 4 days ago, open): Rendering DocBook files
<qyliss> I've been making several PRs related to things he's a maintainer for for the past few weeks and haven't heard anything from him on any of them :(
<gchristensen> jtojnar: cool!
<aanderse> it was an fyi, and maybe it will remind him to take a look
<qyliss> Yeah. Thanks for the ping.
<aanderse> no problem
<aanderse> i was carefully watching your mailman PRs...
<aanderse> until recently when i found out i am able to ditch the mailman instances we have
<qyliss> Aww
<aanderse> which is great news for me... because i wasn't looking forward to taking 2 separate mailman instances from debian 6 or 7 (can't recall atm) and somehow merge+migrating them to anything else
<qyliss> Yeah that doesn't sound fun
<qyliss> I have been enjoying Mailman though
<qyliss> Hyperkitty rocks
<aanderse> i thought "at least i can migrate them to nixos"... but then i found out i can just shut them down, so i'm happy :)
<aanderse> yeah i just found out we run 2 instances at work recently and started digging into them
<aanderse> its a nice piece of software
drakonis has quit [Ping timeout: 248 seconds]
<worldofpeace> qyliss: I think I was just talking about your mailman stuff with spacekookie a few days ago. I'm eager :D
<qyliss> :D
<qyliss> I've been working on it for _months_.
<qyliss> Or rather, I had it working months ago, but it's taken this long to get it into logical, reviewable commits that don't just look like I decided to rewrite the whole thing for fun :P
drakonis has joined #nixos-dev
<qyliss> If you're particularly excited, btw, review is very appreciated! As mentioned above peti doesn't seem to be particularly responsive atm.
<worldofpeace> That's considerate of you qyliss, because those kinds of prs are hard to land and review (not that I wouldn't review it like crazy anyways)
<worldofpeace> > aaron probably just poke @peti with a sharp stick :)
<{^_^}> error: syntax error, unexpected '@', expecting ')', at (string):273:26
<worldofpeace> I've heard from gchristensen that there might be a peti summoning ritual
<qyliss> Yeah I find reviewing modules extremely difficult.
<worldofpeace> Can't really go into the details, because afterwards you have no memory of how the interaction occured. just that it did. I can lend some incense however, if you're desperate
<worldofpeace> qyliss: you can ping me when you open it, I'm just not in the position currently to promise anything I'm afraid
<qyliss> v legit
<qyliss> I opened it a few days ago though :)
<qyliss> #77444
<{^_^}> https://github.com/NixOS/nixpkgs/pull/77444 (by alyssais, 1 day ago, open): nixos/mailman: lots of big improvements
<aanderse> worldofpeace: ha ha ha i don't have any goats blood on hand, but i'm curious to hear what that ritual involves :P
<ryantm> ls
<ryantm> oops :)
<Profpatsch> going to his house and throwing stones at/through his windows, probably :)
<Profpatsch> Or maybe there’s a secret incantation
<Profpatsch> You could try to open an OpenSUSE ticket :P
<worldofpeace> Profpatsch: aaron I think this might involve an incantation, but any materials donated would be much appreciated in times like this
<worldofpeace> anyways, I relinquish #nixos-dev from my daily farsical hijack 🤣
ivan_ has joined #nixos-dev
ivan has quit [Ping timeout: 268 seconds]
<__monty__> tazjin: Can't find where they called it out but here's documentation on it "Code block with callouts" https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/#source-code
<tazjin> __monty__: oof
<tazjin> yeah not a big fan of that tbh
<__monty__> ¯\_(ツ)_/¯ Could be useful.
<tazjin> qyliss: I'm curious why you dropped the systemd StateDirectory stuff?
<qyliss> An excellent question to which I can no longer remember the answer
<tazjin> :)
<__monty__> Did you get rid of the state along with it?
<qyliss> no
<qyliss> tazjin: Oh it's because the directory setup is done by the mailman-setup service now
<tazjin> qyliss: hmm, but couldn't that also have been set up by systemd? (since the statedir is specified by name, it'd be possible to have the two share the same statedir rather than having to set it up in the script & take care of permissions)
<tazjin> not a big deal, but I'd personally be happy if people used the systemd options for managing this stuff (tbh including the service user itself) more
* tazjin has been running git blame --line-porcelain over all of nixpkgs for a while and it's taking *forever*
* gchristensen too
<tazjin> gchristensen: huh :p
<gchristensen> delayed. I mean w.r.t. leading on systemd options which do nice things :)
<tazjin> ah!
<qyliss> tazjin: it would be possible, but it would be more code and there would be zero advantage
<qyliss> The systemd stuff is great most of the time, but it doesn't buy anything here
<qyliss> tazjin: also, this service sets up multiple directories, /var/lib/mailman and /var/lib/mailman-web
<qyliss> So which one would I put as StateDirectory
<qyliss> It would make no sense to put one and not the other
<qyliss> I think _that_ is why I didn't use it.
<tazjin> valid
<aanderse> qyliss: StateDirectory takes multiple directories
<qyliss> Can each one be owned by different users?
<aanderse> oh sorry, i thought it was same user :)
<aanderse> no, definitely not
<qyliss> Yeah
<qyliss> I do like StateDirectory as a rule
<qyliss> And DynamicUser rocks when you can use it
lovesegfault has joined #nixos-dev
Scriptkiddi has quit [Ping timeout: 268 seconds]
Scriptkiddi has joined #nixos-dev
ciil_ has joined #nixos-dev
kenjis has quit [Remote host closed the connection]
ciil has quit [Ping timeout: 260 seconds]
pepesza has quit [Ping timeout: 240 seconds]
pepesza has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.6]
drakonis has joined #nixos-dev
das_j has quit [Ping timeout: 265 seconds]
makefu has quit [Ping timeout: 265 seconds]
das_j has joined #nixos-dev
lovesegfault has quit [Ping timeout: 248 seconds]
makefu has joined #nixos-dev
ivan_ is now known as ivan
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
lovesegfault has joined #nixos-dev
drakonis has quit [Ping timeout: 260 seconds]
<yorick> it sucks when you start having multiple services
<qyliss> multiple services?
<yorick> multiple units sharing a state dir
<yorick> you can do it with JoinsNamespaceOf
<Taneb> I've been trying to figure out the issue with gnustep.base and now I think I know less than when I started
<samueldr> I've not been keeping tabs on those things, what's going on? what's known?
<{^_^}> nixos/nixpkgs#76927 (by tobim, 1 week ago, open): gnustep.base fails with undefined symbol: xmemdup
bhipple has joined #nixos-dev
<gchristensen> so I think I'll probably change the hydra build layout to mark like a quarter of the big machinse big-parallel, with cores-per-job set to like 12 or something
<samueldr> could implementing TAGS in hydra (was it tags?) be another good project for GSOC
<samueldr> I'm thinking about the one that cancels builds and push them to a beefier machine in turn
<gchristensen> that is a really cool idea
<gchristensen> yeah, that is TAGS
<samueldr> my gut feeling is it would *really* help
<gchristensen> same
<gchristensen> I was thinking I could implement a not great version of TAGS in r13y
<samueldr> where should we document good ideas for GSOC?
<flokli> samueldr: if there's not yet a place, maybe just a pad somewhere?
<samueldr> that's why I'm asking :)
<flokli> one second
<samueldr> I don't know where I should send that that would be useful
<samueldr> I'm also thinking of self-contained, mostly conflict-free things
<gchristensen> all the building is local, so not the same exactly but: for a machine with 48 cores, for each derivation build with jobs=48,cores=1,timeout=30; ones that timed out: jobs=24,cores=2,timeout=60; then jobs=6,cores=8,timeout=600, ...
<flokli> (requires login via github or other sso as a simple barrier, else public)
<samueldr> just noting that i18n for nix is really the nix tooling, not nixpkgs and nixos :)
<aanderse> samueldr: are you feeling charitable with your time right now?
<samueldr> depends, kinda re-inventing the world in stage-1
<samueldr> (with great success)
<aanderse> ha ha ha yeah that doesn't sound like something i want to interrupt
<aanderse> keep going!
<gchristensen> I also should probably get back to work and stop chatting about tags :P
<aanderse> nah not me. i just noticed a PR that hasn't been reviewed in 27 days, sitting there. motivation is to run kodi on embedded. i thought you might have an opinion on two on the PR shrug
<{^_^}> #75697 (by georgewhewell, 3 weeks ago, open): kodi: add option for GBM backend
<lovesegfault> I could help (RE: TAGS)
rnhmjoj has quit [Changing host]
rnhmjoj has joined #nixos-dev
rnhmjoj has joined #nixos-dev
<samueldr> how?
<lovesegfault> samueldr: How I can help?
<samueldr> yes :)
<lovesegfault> I'm a SWE, I have some time, I like Nix?
<lovesegfault> Ah, not really, it just seems like an interesting problem
<samueldr> right, the "how?" can be read in so many tones
<lovesegfault> :D
<samueldr> I lost track of any actual documentation about all that from previous discussions though
<lovesegfault> I mean, the fact that Hydra is all perl kind of deters me hacking on it
<lovesegfault> because I do not know perl
<samueldr> it's the web thing that's perl, the other parts are less perly
<lovesegfault> And after working with Rust for a couple years I am now an addict
<samueldr> but I think the initial idea was to implement the nix builder protocol so anything could use it transparently
<samueldr> hydra, in the end, would be none the wiser
<lovesegfault> gchristensen's doc mentions that approach
<lovesegfault> So I guess it'd be cpp to make use of all the Nix libs?
<samueldr> with the current interest for rust-with-nix it might be possible to do it in rust
<gchristensen> I would recommend not doing that actually, and instead try doing it in hydra-queue-runner
<gchristensen> (C++)
drakonis has joined #nixos-dev
__monty__ has quit [Quit: leaving]
<evanjs> samueldr: gchristensen yeah my initial thoughts after reading the discourse thread and etc were that it might be best to try it with small apps outside of nix core like samueldr’s nix-top. Though, okay, that was more just me wanting to RiiR, fine.
<evanjs> Anyway, nix utilities that are not central to infrastructure and operations might be a good first target
<samueldr> my (possibly) wrong opinion is that a prototype implementation in any language is better than none; even if there is the need to rewrite it, it's likely to show the warts and bugs first
<samueldr> (possibly wrong)*
<samueldr> though yeah, for what you're looking at, it's likely good
<samueldr> and evanjs, having a nix-top that actually has knowledge about the daemon rather than a hack that looks at the filesystem would be great
<evanjs> samueldr: totally agree. Trying my best not to let my bias/rustlove not outweigh my reasons whenever I bring it up for such discussions is all :P
<evanjs> samueldr: yeah my initial focus for it was system-level stuff without bash
<evanjs> as Rust _is_ a systems language haha
<samueldr> nix-top is free of bash :3
<evanjs> samueldr: sorry, right, shell wrangling is more what I meant haha
<samueldr> I didn't exactly take it personally, I wasn't sure if that was aimed at nix-top
<evanjs> no I get it, I just have a bad habit of not clarifying/providing enough context at times
drakonis has quit [Quit: WeeChat 2.6]
drakonis has joined #nixos-dev
hexa- has quit [Quit: WeeChat 2.7]
hexa- has joined #nixos-dev