gchristensen changed the topic of #nixos-chat to: NixOS but much less topical || https://logs.nix.samueldr.com/nixos-chat
waleee-cl has quit [Quit: Connection closed for inactivity]
drakonis_ has joined #nixos-chat
drakonis has quit [Ping timeout: 276 seconds]
drakonis has joined #nixos-chat
aszlig has quit [Quit: Kerneling down for reboot NOW.]
aszlig has joined #nixos-chat
drakonis has quit [Read error: Connection reset by peer]
endformationage has quit [Ping timeout: 240 seconds]
<eyJhb> I cannot express, how much I hate the French Valve on my bike. I just got a flat, not because of any sharp objets, but because the tiny head thing broke off... Like, how often do you get a flat, while pumping your bike
<joepie91> lol :(
Arahael has joined #nixos-chat
<Arahael> I want to start a custom service (that uses docker) as a systemd user service, how do I get started?
<Arahael> What documentation do I need to read to set that up?
<Arahael> As a trivial example, I want to run syncthing automatically, that's not a docker service though, but the other services I want to run are docker based services.
<Arahael> I suppose I can just do it the usual systemd way, and ignore anything special nixos might give me.
<emily> look at the option documentation for systemd.services.* is one option
<emily> I think there might be a section of the nixos manual about it too?
<emily> oh, for users there's another copy of those same options under the user I think
<emily> ah, no: `systemd.user.services` is what I have
<Arahael> emily: Where's that?
<emily> https://nixos.org/nixos/options.html search for systemd.services, systemd.user.services
<Arahael> emily: How do you find that page? I was looking for any mention of 'systemd' at https://nixos.org/nixos/manual/
<emily> it's linked in the header
<emily> the docs aren't great, it's not your fault, the discoverability of the actually useful material is pretty low
<emily> I suggest bookmarking the page or something
<Arahael> Yeah, I think I'll do that, I guess I'm asking for questions that'd help me discover things myself.
<emily> hanging out on IRC is a good first step I'd say
<Arahael> For instance, that options page is actually only mentioned in section 17 of the manual for prometheus exporters.
<Arahael> emily: I should totally hang out here more often. :)
<emily> also, keeping a local checkout of nixpkgs and just grepping it if all else fails
<emily> I prefer that to `nix search`ing for packages, personally...
<emily> all the docs and everything are in the repo, so you should be able to find what you need in there if you look hard enough
<Arahael> I should do that too - actually that's on my todo list, to figure out how to fork that.
<Arahael> Though I could probably just fork it on github and then use that, but I wonder what the benefit is.
<Arahael> Makes more sense, imho, to fork it "locally" - ie, just git clone it, and then use that tree directly - anyway, that's on the todo list.
<emily> generally you want to use the nixos-channels repo
<emily> so that you can sync it to the channel you are using
<Arahael> Well, I want to modify the gramps .nix at some point to add some more python dependencies to it.
<Arahael> (*not* today, though)
<emily> you can clone the nixpkgs repo and add nixos-channels as a remote
<emily> I generally base the branches I upstream to nixpkgs on one of the nixos channels so that I can test it locally with binaries.
<Arahael> How do you 'test it locally with binaries' like that? Don't you need to add it to the nix channels thing?
<emily> I have nixpkgs=/path/to/my/checkout in my NIX_PATH
<Arahael> I must find out where my nixpkg's point to!
<Arahael> Both are empty.
* emily just doesn't use the normal channels machinery at all, I do it all through git. but that might not be to your tastes
<eyJhb> Arahael: have you looked at the new services.docker-containers option?
<eyJhb> Don't know if that applies to you, but that is a docker container managed with systemd, somewhat
<Arahael> eyJhb: Well, thanks to emily, I think I know now that I could copy that into the website, and... No, there are no matching options found. :(
<Arahael> emily: I use git every day. The normal channels machinery... Isn't something I fully understand.
<emily> then you might find the nix-channels repo the most comfortable way to manage this stuff, I do
<emily> I keep personal patches on a branch I base on top of channels/nixos-unstable
<Arahael> emily: I'm just not sure how to do it, without unintentionally mucking this magic up.
<eyJhb> Arahael: it is in unstable, so there is no documentation for it in option, if that is what you mean
<Arahael> eyJhb: I do seem to have the unstable channel (in addition to the nixos-19.03 one, as root)
<Arahael> eyJhb: The problem is one of discoverability.
<Arahael> As a "new" nixos user (well, I've been using nix for a while now, but not actually _learning_ it)... I struggle with trying to figure out how the heck I should do stuff.
<eyJhb> If you have the channel, then you can import the docker-containers by using `<nixos-unstable/nixos/modules/virtualisation/docker-containers.nix>` in your imports (configuration.nix), and use it like etu has done here - https://github.com/etu/nixconfig/blob/81645da1670fdb16bc3477f27f68cbde1f2583e5/hosts/fenchurch/services/magic-mirror.nix#L5-L12
<eyJhb> But currently bike fixing, so I might be slow to reply. Also #nixos would be more appropiate for this :p
<Arahael> eyJhb: That just causes so many more questions! Lets start with the first one: "If you have the channel" - uh, why wouldn't I?
<Arahael> And what's that <nixos-unsable/nixos/modules...> syntax? I've seen <nixpkgs> before, but never with a longer path in it.
<Arahael> I'm still very slowly figuring out how to use it for my own software.
* Arahael probably should do the pills.
<eyJhb> Arahael: if you have the unstable channel added `sudo nix-channel --list`, which will show the channels you have, it should be something like `<local-name> <url>` e.g. `nixos-unstable https://nixos.org/channels/nixos-unstable`, if you do not have the unstable channel, you can add it with `sudo nix-channel --add https://nixos.org/channels/nixos-unstable nixos-unstable`, the syntax
<eyJhb> <nixos-unstable/....`, refers to the local channels you have. So in the list you would have seen `nixos`, so anything that does `<nixos/....`, uses that channel, and the syntax I showed you would use the nixos-unstable channel (if you have called it by that local name)
<eyJhb> Hope that somewhat makes sense
<Arahael> eyJhb: I added the unstable channel a while back (so that I could get a newer gramps installed)
<Arahael> eyJhb: So, the '<>' are kind of a quotation symbol that says: "This path belongs to a nix-channel that has previously been added"?
<eyJhb> You could say it that way yes :)
<Arahael> eyJhb: I'd rather know the correct way to think about it - my background is that I'm a developer.
<Arahael> I do prefer to understand how things work from the fundamentals up.
<Arahael> Rather than try to figure out / guess how the fundamentals work given the examples of using nix-env.
<Arahael> Just been looking at that etu/nixconfig repo, it's a nice way of versioning the nix environment, looks nifty.
<Arahael> I don't understand the need for the submodule, though. (the nixpkgs one)
jD91mZM2 has quit [Quit: ZNC 1.7.3 - https://znc.in]
<eyJhb> Arahael: I don't know the 100% correct terms ;) There is also infinisil configuration, and gchristensen ! Generally, nice looking at other peoples configs for inspiration.
<eyJhb> The submodule? docker-containers?
<eyJhb> Because it isn't in stable
<eyJhb> So unless you run nixos with the unstable channel on it, then it won't work :)
<emily> Arahael: <foo/...> looks up foo in the Nix path / NIX_PATH
jD91mZM2 has joined #nixos-chat
<emily> Arahael: channels get automagically inserted into the Nix path
<emily> looks like etu uses a git submodule to pin to a specific nixpkgs version like I do
<emily> rather than using the channels machinery
<Arahael> emily: I'm kind of curious now because I don't seem to even have a nix path.
<emily> yeah, for you it is probably composed entirely of the channels
<Arahael> emily: I'm actually running nixos, in this case, so should be a pretty standard setup...
<emily> the standard setup has an empty NIX_PATH and uses channels for everything
<Arahael> eyJhb: Somehow, I suspect that it's probably not going to be helpful to figure out hwo to get into this docker-containers thing. Ended up doing it by hand, manually (by writing the systemd service files directly in ~/.config/systemd/users/)
<Arahael> Most of my nixos experiments at home have been trying, in vain, to figure out yet another way to build a haskell script I've written.
<Arahael> Which had been a bit frustrating.
<Arahael> (Mostly because it seems that every other month, the current LTS build in stack seems to be different - so the new stack project wont' build in nix, or as what happened previously, my existing stack projects wouldn't build after I upgraded nix, etc)
<Arahael> (Still much better than the likes of homebrew - I'm only frustrated, not discouraged)
<qyliss> I'm surprised to hear upgrading Nix broke your builds
<Arahael> qyliss: It was because the ghc that the stack LTS channels used was removed or something.
<qyliss> oh, you mean upgrading Nixpkgs?
<Arahael> Yes.
<qyliss> aha, that makes more sense
<Arahael> Well, I was quite surprised, as I hadn't done a garbage collection or anything. Turns out that stack, when in "nix' mode, will directly refer to the current channel or something obscure.
<qyliss> fwiw, I also use a local source repository for Nixpkgs rather than channels
<qyliss> channels can be quite difficult to manage, because even if you version control your configuration you don't know what channel version it was built against
<Arahael> qyliss: One wonders how you discovered that.
<Arahael> I don't think this is mentioned in the manual - and even if it was, I wouldn't be at the level to understand the implications of that decision. :(
<Arahael> Plus, I suspect stack uses channels, and therefore wouldn't be using a local source repository for nixpkgs.
<qyliss> It's not an ideal solution. We're aware of the ergonomic issues with channels and there is a plan to replace them.
<Arahael> I've probably gone into the deep end by trying to use nix from the get go within a language ecosystem - eg, python, haskell, stack, and all that - I get the impression that those are effectively custom built by the nix developers who use those languages.
<Arahael> qyliss: The bigger problem is probably that I am wishing that there was more of a hand-held "guide" to doing various tasks with nixos.
<qyliss> Yes, more of those are always good
<Arahael> The manual doesn't tell you how to package up a relatively simple python package that uses a requirements.txt, as an example.
<qyliss> As you might expect, we always need more documentation writers than we have
<qyliss> But I recently helped publish an equivalent manual section for Ruby, for example
<Arahael> Could you show me that?
<Arahael> I do use ruby. :)
<Arahael> qyliss: (Note: If I look at the nixos manual, and do a ctrl-f for 'ruby', nothing is shown)
<qyliss> aha! I think I may have found your problem :)
<qyliss> you should be looking in the nixpkgs manual for these things
<qyliss> because it's not NixOS specific
<qyliss> The NixOS manual tells you about NixOS modules and services and stuff
<qyliss> Package stuff is all in the Nixpkgs manual
<Arahael> *sigh*. I think you are exactly correct.
<qyliss> Lots of people mix them up.
<emily> I was about to say, the nixpkgs manual does have a fair bit about Python packaging
<qyliss> We should probably just have one big manual tbh
<Arahael> Btw... The nixpkgs manual isn't even mentioned anywhere on https://nixos.org/nixos/support.html
<qyliss> Note, however, that the manuals are for 19.03, the latest stable version.
<qyliss> So our new Ruby stuff won't appear there until 19.09 comes out
<qyliss> There's no way that I know of to view the latest unstable version of the manual, short of building it yourself. This is another problem, because if you actually want to contribute to Nixpkgs that's what you need to read.
<qyliss> Wow, you're right. We should definitely put it in the other resources section, at least.
<qyliss> That would be an extremely easy change.
<Arahael> Yeah, well, clearly first I need to familiarze myself with the nixpkg's manual. I'd been reading the nixos manual, finding it pretty... useless... And then thinking that I have to do things the hard way and try going through all the nix pills instead. (Which I'm still slowly doing )
<Arahael> qyliss: Absolutely needs to be referenced in an obvious location - such as indeed, 'other resources'.
<qyliss> Arahael: would you like to make a PR to add it? https://github.com/NixOS/nixos-homepage/blob/master/nixos/support.tt#L64
<qyliss> I'll do it if you'd rather not.
<Arahael> qyliss: Id' rather you do it, for a few reasons: 1) It's starting to get late for me and 2) I don't know how to test that and display it locally to see how it looks.
<qyliss> Okay, np :)
<qyliss> Thanks for coming and talking to us on IRC. It's good to hear what people struggle with, and it's a good way for users to get help. I hope you stick around. :)
<Arahael> qyliss: I might even suggest that maybe nixpkg's shoudl be it's own section, with a blurb: "This is the underlying stack, for information about... you'd be best to consult the nixpkg's manual, available HERE", or something like that.
<qyliss> hmm. I think it definitely belongs in the same place as the Nix manual
<Arahael> qyliss: I intend to stick around - been around for a couple of months, at least. But usually I'm frustrated with not being able to find resources when I chat in the channel - so I'm very grateful that you've finally identified the missing links here. :)
<qyliss> And the wiki is so good as well it really makes sense to keep them all together I think
<Arahael> Yeah, wiki isn't neccessarilyt hat useful for newbies, I suspect, though, because it has a different feel to them.
<Arahael> When you're trying to figure something out, being very new to it, you want to be on well-trodden stuff.
<qyliss> Yeah
<eyJhb> Isn't the manual big enough as it is qyliss ? :p
<Arahael> There is another gap as well - the nixos manual seems more interested in showing you how to use configuration.nix, etc. And a glance at nixpkg's manual seems to suggest that it's mainly interested in showing you how to write packages, and to be a reference...
<Arahael> eyJhb: It's definitely not big enough.
<Arahael> However, there's still a gap in showing you how to discover things, like, how to determine what the available settings are and to diagnose and resolve any problems.
<Arahael> Eg, the original question today I had: How do i do add a systemd user service? ;)
<eyJhb> Arahael: examples. Examples examples examples. I normally use the nixpkgs repo for that
<eyJhb> Or look at other peoples configs
<eyJhb> AND! Your question was more specific, to use docker+sytsemd
<Arahael> The nixos manual, I suspect, would show me how to add a _specific_ systemd user service, but not show you how to add a custom one. emily's suggestion to use teh options search did help some of the discovery, but then I was left with like, "how do I actually add these options to the configuration.nix file? How do I do this as a *user*, anyway, configuration.nix is system-wide..."
<Arahael> eyJhb: I don't think the docker part of it was a significant difference.
<eyJhb> It was, as there is a module with that specific purpose :p
<Arahael> eyJhb: I wanted to use docker-compose.
<eyJhb> So if it was a generic "how do I add a systemd service", I would never have mentioned the specific module
<Arahael> Ah, fair enough.
<emily> Arahael: ah, if you want per-user specific config then that's out of the core nixos toolset
<emily> like without doing it in configuration.nix
<qyliss> Arahael: have you seen home-manager? It's like a user-specific configuration.nix
<Arahael> I probalby should've mentioned; "I have a specific docker-compose.yml file here, and I start it using 'docker-compose up' - how do I schedule that as a systemd user service?" :)
<eyJhb> Would have made sense yes, but all the configs needed can be seen in systemd.services.<name>, but it is somewhat annoyign
<Arahael> I've seen home-manager mentioned a few times, I probably really should use it.
<eyJhb> But if you have made a service file already, it should be EASY to add to your configuration.nix
<Arahael> eyJhb: I guess when I look at that file - eg, docker-containers.nix, I wonder how to add it to the configuration file. I mean, configuration.nix file feels to be literally just a dictionary, and I have very little idea as to what the keys should be.
<Arahael> It's magic, how that configuration file gets consumed.
<emily> the keys are as documented by options.html
<eyJhb> That is where that comes in
<emily> you can just do
<emily> systemd.services. ... = ...;
<Arahael> emily: At risk of being intentionally obtuse... Would you suggest I do: systemd.services.user.docker-containers = { ... the options I want from the docker-containers.nix file ... }
<Arahael> emily: What I mean, is I don't know what the LHS should be, and how to specify which actual configuration I want in the RHS.
<Arahael> I mean, I never actually see anything import that file explicitly.
<etu> emily: [pinned nixpkgs] I do both, on my stable branch systems I use the channels and usually auto upgrades :)
<etu> emily: But on systems where I want more control and being able to dig in to nixpkgs and test things with less work I use the pinned one :)
<qyliss> Arahael: you can import other files, but when you're getting started it's usually easier to just have one big one
<Arahael> qyliss: I am not really sure how to express myself at the moment, what I"m trying to say is - lets assume I indeed want to use that docker-containers.nix file you've shown me.
<qyliss> You may already know this, but if not: systemd = { services = ...; }; is equivalent to systemd.services = ...;
<qyliss> not sure if that helps
<qyliss> OH, I see what you're asking
<Arahael> qyliss: Yeah, that I've figured out. :) Anyway, lets assume I want that docker-containers.nix file - how do I specifically refer to the options on lines 168 to 190 in configuration.nix?
<qyliss> Those are part of, essentially, a private function
<qyliss> So you can't
<Arahael> qyliss: So there's no point even looking at it, then, right? ;)
<qyliss> The only way to interact with them is through the interface exposed by the docker-compose module
<qyliss> Well, it might give you inspiration
<Arahael> Oh? So I should look at the top of the docker-containers.nix file, which I'm going to guess is probably going to be a function that takes a set as an argument... And then look to see how those arguments map to lines 168 to 190... But then the problem is that nothing ever actually imports it in the first place.
<qyliss> it's imported by nixos/modules/module-list.nix, but that's an implementation detail that shouldn't matter to you
<Arahael> qyliss: But it does apparently matter, because I need to somehow figure out the interface? :)
<qyliss> You _should_ be able to use options.html, but unfortunately you can't because this hasn't made it into stable yet
<qyliss> (Our infrastructure is really geared to stable and it can be tricky to do things for unstable. This is another problem we need to fix.)
<Arahael> Yeah, I"m not actually worried about that particular issue, that can be worked around - as a newbie, I probably really should properly understand /stable/ first.
<qyliss> So, in your configuration you can set docker-containers.whatever.cmd, docker-containers.whatever.environment, etc
<qyliss> Does that help?
<qyliss> And then from that it will generate you a systemd service using the function you saw
<Arahael> qyliss: Ah, so module-list.nix imports all the modiles... And evaluates them all, so that they all add their options to the global options list, which then lets me, the sysadmin in this case, provide new values for, and then the result is evaluated in some sort of transform that results in a new nix derivation?
<qyliss> pretty much!
<Arahael> qyliss: How does it manage to separate declaration of the inputs, and the transformation into the new (system wide) derivation?
<Arahael> I mean, there surely has to be _some_ imperative stuff happening.
<qyliss> the 'config = ' part is where it sets values of options
<qyliss> the 'options.* = ' part is where options are declared
<qyliss> In terms of generating a derivation, no imperative stuff happens (practically)
<Arahael> Lets take this particular line as an example line 224: systemd.services = mapAttrs' (n: v: nameValuePair "docker-${n}" (mkService n v)) cfg;
<Arahael> Somehow, that sets the systemd.services, and simultaniously, *reads* the attributes from the services?
<qyliss> It's not reading the values from it
<qyliss> At least I don't think so
<Arahael> qyliss: cfg comes from config.docker.containers, which I presume is originally set in configuration.nix
<qyliss> Oh, right
<qyliss> But it's not reading from config.systemd.services
<qyliss> If it did that, it would be infinitely recursive
<qyliss> But the value config.docker.containers doesn't depend on config.systemd.services
<qyliss> So it's fine for systemd.services to refer to it
<Arahael> Well, it's lazy, so presumeably it only recurses as far as required.
<qyliss> because it's one-way
<qyliss> exactly
<Arahael> Ok, so this config thing is basically a massive, massive nested dictionary that keeps on growing and expanding until it's finally evaluated.
<qyliss> yeah
<qyliss> technically, it's a set of nested dictionaries that can refer to each other and are merged together at the end
<qyliss> that's why setting systemd.services in one module doesn't override the systemd.services set by another module
<qyliss> they're all merged together
<Arahael> I think I vaguely understand that now.
<qyliss> It'll feel more natural the more you're exposed to it
<Arahael> qyliss: You've certainly given a lot of enlightenment for tonight. :) I think I should take a break and let it absorb a bit. :) And perhaps take another look at the nix pills *and especially* a read of the nixpkg's manual.
<eyJhb> You always forget about timezones when chatting..
<Arahael> eyJhb: What timezone is it for you? :)
<Arahael> (GMT+10 here)
<eyJhb> GMT+2, so it is 2 PM here :p
<qyliss> +1 here
<Arahael> Heh, nice. :)
<eyJhb> qyliss: what country?
<qyliss> Scotland
<Arahael> qyliss: The land of Robert the Bruce!
<eyJhb> Ah! Nice :)
<emily> Iceland doesn't do BST so I think UTC+1 is uniquely occupied by Great Britain + Ireland during summertime?
<emily> er, *doesn't do DST
<Arahael> emily: Also, thanks for your help earlier, too. :)
<Arahael> Made me feel welcomed.
<eyJhb> Ah... I was so confused, because I remember Denmark being UTC+1, but +2 because of summertime..
<eyJhb> Someone throw that out the window, and soon
<emily> Arahael: no problem! if there's one takeaway, it's pretty normal to be confused about nix{,os,pkgs} :p
<emily> but you do start getting the hang of it once you've packaged a few things and started to understand the model
<qyliss> Portugal is the same TZ as UK/IE I think
<emily> and you get a ton of nice benefits in your build and development environments for free once you do
<Arahael> emily: It doesn't help that I'm trying to apply what I learn to the macos version.
<emily> ahh
<emily> in that case, all of the NixOS modules are irrelevant to you
<emily> I think home-manager supports macOS, and there's also nix-darwin
<eyJhb> qyliss: It was weird when I flew to Cape Town, because it is in the same time zone as Denmark. Like flying for 11 hours straight, and still being in the same timezone. That is just.. Not what you expect
<Arahael> Not really - my home computer uses nixos... And it's quite nice there. I don't have nix on my personal macos system - but I do at the work mac system.
<emily> ah, I see
<Arahael> (It's a bit awkward - mostly I'm keen to learn nix, but most of my learning scome from the nixos system and at work I occasionally try to figure out how to do the 'same thing'.
<emily> you should be able to share your builds and development environments, just not your system services and configuration, basically
<Arahael> And I don't have nix on my personal mac system because nix is HUGE, and I don't really have the space - brew is more efficient)
<Arahael> Well, sadly, at work I usually use xcode, so that's a huge complication.
<emily> Nix is a plot by SSD manufacturers: the next time you upgrade your system you will find yourself paying through the nose for a 2 TiB SSD so you can use Nix for all the things.
<Arahael> So mostly I try to use nix for a few utility services, that just happen to be either python utilities, haskell utilities, or ruby gems.
<eyJhb> Arahael: comparing the two doesn't make much sense
<Arahael> eyJhb: I didn't really realise there was a comparison involved. Afterall, isn't it all 'nix'?
<eyJhb> Between brew and nix :p
<Arahael> Oh, ha! :)
<Arahael> Actually no, it does make sense to compare brew and nix, but only superficially.
<Arahael> You can install packages with either system - but nix takes a heck a lot more space to do so!
<qyliss> having previously written a bunch of brew, I could compare them for hours
<eyJhb> *and does a heck of a lot more
<eyJhb> :p
<qyliss> part of Homebrew's goals starting out were to not use much disk space, and rely on stuff already on the system
<qyliss> Because MacPorts liked to build its own copies of everything, like Nix does
<Arahael> And nix, on the mac, uses a crazy amount of space.
<emily> unfortunately, as you probably already know, Apple,
<Arahael> Apple isn't exactly cooperative, either, yeah. :(
<Arahael> I tried to use xcode within a nix package. Basically gave up.
<qyliss> They find some exciting new way to break Nix every release
<qyliss> You might want to check out xcbuild for that, fwiw
<emily> hard to not bundle stuff when the base system keeps losing things
<qyliss> It's like, a reimplementation of the Xcode CLI, as I understand it
<Arahael> qyliss: Back when I looked at it, it was broken. My work project is pretty new sometimes - heck, we're already using XCode 11.
<Arahael> Also... When I say I use xcode... It's because I"m doing iOS stuff.
<Arahael> Which does... Weird stuff, sometimes!
<{^_^}> nixos-homepage#307 (by alyssais, 33 seconds ago, open): nixos/support: link to nixpkgs manual
<Arahael> qyliss: Awesome - +1'ed it. :) ANd yes, that description is spot on.
avn has joined #nixos-chat
avn has quit [Read error: Connection reset by peer]
avn has joined #nixos-chat
<eyJhb> qyliss: will you make a PR so that options support unstable and other branches too? ;) :p
<qyliss> I think that might be a bit too involved for me right now ;)
<eyJhb> Awww... :( It seems rather doable! I might look at it at some point
<eyJhb> I really need it sometimes, also it is quite nice to have
<qyliss> I usually just use grep tbh
<eyJhb> My downstairs neighbour is banging shitty music..
<eyJhb> But that doesn't give you the pretty layout qyliss :p
<eyJhb> I mostly like options.html, because it display children/parents well
<qyliss> Occassionally I use nixos-option
<eyJhb> If nixos-option did a tree like view, I would be soooo happy
<qyliss> that's a good idea
<eyJhb> Would make things easier, I might look at it
<eyJhb> But first I have the remaning 10 items on my todo list, and I need to screw around with iptables
<eyJhb> I should get a book on iptables, our iptools2 (as I also need route stuff)
endformationage has joined #nixos-chat
jD91mZM2 has quit [Quit: ZNC 1.7.3 - https://znc.in]
jD91mZM2 has joined #nixos-chat
<eyJhb> Anybody who knows word generators for phone numbers? Like, when you type in a phone number on a T9 keyboard, then instead of numbers you could easily translate it into a word instead, like what is somewhat common in US
<samueldr> use a t9 keyboard and write down your phone number :)
<eyJhb> That's waaay too easy samueldr ! :p
<eyJhb> Actually my number has a "1" in it, which sucks :/
<MichaelRaskin> Argh. What I want: given 50 to maybe 500 hundred headlines, sort them in an order that should typically bring headlines on the same topic together. No state and language independence would both be plusses. What I get if I try searching: given a 1000 to 10000 documents of at least one paragraph, assign topic labels to them, based on a model trained on a million documents or something.
drakonis has joined #nixos-chat
drakonis_ has quit [Ping timeout: 276 seconds]
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-chat
drakonis_ has joined #nixos-chat
drakonis has quit [Ping timeout: 245 seconds]
spacekookie_ has joined #nixos-chat
hyperfekt_ has joined #nixos-chat
hyperfekt has quit [Killed (cherryh.freenode.net (Nickname regained by services))]
hyperfekt_ is now known as hyperfekt
aleph- has quit [*.net *.split]
spacekookie has quit [*.net *.split]
lassulus has quit [*.net *.split]
aminechikhaoui has quit [*.net *.split]
clever has quit [*.net *.split]
aminechikhaoui has joined #nixos-chat
aleph- has joined #nixos-chat
lassulus has joined #nixos-chat
spacekookie_ is now known as spacekookie
drakonis has joined #nixos-chat
drakonis_ has quit [Ping timeout: 245 seconds]
<tilpner> This is all sorts of horrible... :/ https://tx0.co/bMG
<tilpner> Reusing submodules while defining overlapping submodules feels so brittle
<tilpner> elemAt 0? That might switch order at any moment for all I know
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-chat
<eyJhb> Sooo... Today I learned what i feels like getting stuck in sand, and having most of my car front just nosediving into it
<eyJhb> WOUld not recommend at all
drakonis_ has joined #nixos-chat
<hyperfekt> tilpner: Yeah I mostly gave up on stuff like that. It hurts to write and it hurts to look at, and it will probably hurt to debug :/
<tilpner> hyperfekt: It's so nice though :/
<tilpner> If it works and you don't have to touch it, thar is
<tilpner> *that is
<hyperfekt> That's true. I found it a thousand times easier to just patch nixpkgs instead, especially for the more complex stuff.
<hyperfekt> But still I can't refrain from trying regularly to do it this way.
Arahael has quit [Ping timeout: 276 seconds]
<eyJhb> I suspect it would make more sense, if one knew how to read that
<eyJhb> What is wrong with it tilpner hyperfekt ?
<tilpner> eyJhb: elemAt options.services.nginx.virtualHosts.type.functor.wrapped.getSubModules 0;
<tilpner> And the next line
<hyperfekt> It's just insanely unergonomic to reify options like this
<eyJhb> hyperfekt: please don't make me
<eyJhb> tilpner: I think I need to be more into it, to know what it means and why I should hate it
<tilpner> It's just really ugly
<tilpner> And feels brittle
<hyperfekt> And complicated to figure out if you're not intimately familiar with the module system
waleee-cl has joined #nixos-chat
Arahael has joined #nixos-chat
ajs124 has quit [Quit: Gateway shutdown]
ajs124 has joined #nixos-chat
drakonis_ has quit [Ping timeout: 276 seconds]
drakonis_ has joined #nixos-chat
<eyJhb> infinisil: I found a channel with networking gurus :p So now everything works
drakonis_ has quit [Ping timeout: 276 seconds]
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-chat
drakonis_ has joined #nixos-chat
tokudan has quit [Quit: Dunno.]
tokudan has joined #nixos-chat
drakonis_ has quit [Ping timeout: 265 seconds]
drakonis has quit [Ping timeout: 252 seconds]