<acowley>
I'm still debugging this thing where I have a library (tensorflow) that causes jupyter (console or notebook) to die with a "terminate called after throwing an instance of 'std::bad_cast'". The python interpreter itself is fine, and, interestingly, ipython (non-notebook) works. So what is jupyter-console or the notebooks doing differently to cause this?
<acowley>
It seems like it must be a linked library being the wrong version.
<acowley>
But I'm having trouble even identifying the parts of the system I can point ldd at, and what I can see looks fine.
magnetophon has joined #nixos
<jasongrossman>
New exwm question. I've been trying to use the exwm window manager, with a very simple NixOS configuration, and I get all sorts of bugs - all sorts of things that don't work the way the manual says they should. The reason that's strange is that I can't find anything on the web that suggests that exwm is particularly buggy. Anyone know whether there's any interaction with NixOS?
<jasongrossman>
orivej has quit [Ping timeout: 276 seconds]
<{^_^}>
[nixpkgs] @nicknovitski opened pull request #48494 → xcpretty init, and connect updateScript to fastlane → https://git.io/fxus7
<{^_^}>
[nixpkgs] @peti pushed to haskell-updates « hackage-packages.nix: automatic Haskell package set update »: https://git.io/fxush
<colemickens>
some of mine were "not-detected" and the module it pulls in for that enables redistributable firmware.
<colemickens>
If you want to see some actual hardware-configuration.nix examples, you can peak at my nixcfg files https://github.com/colemickens/nixcfg (look under devices/ I think)
<clever>
drakonis: kexec can sometimes break the gpu card state, the machine will appear to be locked up, but will respond over ssh
<drakonis>
sounds like my issue
<drakonis>
i don't have a way to ssh into my machine
<clever>
ive used kexec to install nixos, remotely, with zero console access, and yeah, its an all or nothing, with no chance to fix mistakes
<drakonis>
there's nixos_lustrate for in place installs
<clever>
yeah, that one likely has the best chances of working, at the cost of having to obey the current partition layout
<drakonis>
i wouldn't mind doing that anyways
<clever>
lustrate can basically upgrade a single-user nix install into full nixos
<drakonis>
fair
<clever>
ive manually done lustrate on 2 machines, prior to it being automated in nixpkgs
<Church->
clever: Much experience with home-manager?
<drakonis>
i have moved in my configuration files and i'm now tossing up a coin to decide whether i should do it right now or wait until tomorrow's test is over
<clever>
Church-: none
<Church->
Aye fair enough.
<drakonis>
automated?
<Church->
Hmm, might just manually write my i3/config file with nix until I can find somebody to help me debug this.
<clever>
drakonis: i manually forced nixos to update the bootloader on a gentoo machine, then debugged all the problems gentoo files in /etc cause, and eventually did an rm -rf / to "fix" it and only leave /boot and /nix behind
<clever>
drakonis: and the story of how i did that, was then automated into a script inside the nixos initrd
<drakonis>
ah yeah my only issue is that i don't want to murder windows
<Church->
Is there a manual or good example on using writeTextFile?
<clever>
if /etc/NIXOS_LUSTRATE exists, it will move everything in / to /old-root/
<clever>
drakonis: that includes the old /etc with the trigger file
<drakonis>
i'll just let it move the windows boot files to old root then copy them back after i'm done
<drakonis>
i absolutely have no usb drives to fix it if anything goes awry :|
<drakonis>
and i know it should be safe, but still
<clever>
drakonis: nixos also needs full control of /boot, so you cant just move the old config back
<drakonis>
i just need to move the windows efi folders rather
<drakonis>
i'm running efi over here and all i need to do is copy the relevant windows things, fedora efi files be damned
<clever>
drakonis: the lustrate stuff fires when / is mounted, before /boot is mounted
<drakonis>
aight
<clever>
so the /boot files on the fat32 ESP will survive
<drakonis>
so i have /boot in one partition and /boot/efi at another
<drakonis>
so nothing goes wrong?
<clever>
as long as you configure that correctly in nixos, it should work
<drakonis>
hardware detection picked up the scheme so it should work correctly
<drakonis>
i did move my kernel images to /boot
<clever>
ensure that your hardware-configuration.nix knows to mount both, that efibootmgr -v lists the right paths for nixos, and that boot.loader.efi.efiSysMountPoint = "/boot/efi";
<drakonis>
yes that's my setup
<drakonis>
i still have the nixos efi entries :v
<clever>
then `touch /etc/NIXOS_LUSTRATE /etc/NIXOS`, nix-build nixos, and `./result/bin/switch-to-configuration boot` will update the efi vars and /boot
<drakonis>
nix-build nixos doesn't actually work tho
<clever>
nix-build '<nixpkgs/nixos>' -A system -I nixos-config=/etc/nixos/configuration.nix
<clever>
ive memorized far too much code for my own good, lol
<clever>
within my head is chunks of linux kernel source, nix, nixpkgs, nixops, and the ghc internals, just to name a few things ive devoured, lol
lord| has quit [Ping timeout: 245 seconds]
lord| has joined #nixos
<clever>
and grub, and qemu
<drakonis>
grub? o boi
<clever>
ive memorized too many codebases, and i cant even remember the names of what ive memorized
<tnks>
I know Travis can cross-compile Haskell libraries, but does anyone use Nix to do this locally before pushing? My worry is that Nixpkgs is kind of dicey for anything other than ghc843.
dvim has quit [Ping timeout: 272 seconds]
<clever>
drakonis: i recently discovered that grub has a full acpi implementation, and that stuff aint simple
<tnks>
I could just use Stack for local cross-compilation... but then that's just a sadness because I'd prefer Nix.
<clever>
tnks: i think the haskell cross-compile stuff in nixpkgs just works automatically now, based on the same flags as the rest of the cross-compile
<tnks>
clever: oh, I should have said "cross-compile" differently. I didn't mean platform, I meant for different GHC versions. Or is that what you meant?
<clever>
tnks: ah, i'm mainly using 8.2.2 from the 18.03 channel, but i believe all of them should work mostly the same
<tnks>
clever: how do you choose channels for Haskell development?
<clever>
tnks: its more that we started before 18.09 came out, and havent switched over yet
<tnks>
for lack of a better idea, I just go with nixpkgs-unstable, but maybe that's too cutting edge?
<tnks>
right now, that's working fine for 8.4.3, which is good. I'm building for 8.2.2 right now, but nothing's cached, so it's taking a while.
<clever>
tnks: i would just start on nixpkgs-unstable, and run, and if you do run into any problems, you can try an older one
<clever>
last week, i started messing with the haskell framework in nixpkgs again, and after building 2 copies of ghc, i had to rebuild the whole haskell ecosystem twice as well, which several hours of churching away
<tnks>
clever: and the JVM people complain about "downloading the internet." They have no idea they could be "recompiling the internet."
<teto>
On unstable I run `nix run nixpkgs.gnome3.gnome-terminal`, then I $gnome-terminal but it ends with ` # Error creating terminal: The name org.gnome.Terminal was not provided by any .service files` :'(
<srhb>
teto: It's a bit unfortunate that some things require special paths rather than just store existence, but it is the way it is..
<srhb>
I don't know if the shell environment could somehow provide the necessary knowledge to systemd/dbus through environment variables or something...
<hyper_ch2>
srhb: well, I still can't everything in ocrmypdf to properly build on nixos... a limited version exists but it does not have stuff like deskew.... so, ocrmypdf also provides docker (it's 3 files) and I've been wondering how to use that on nixos
Thra11 has quit [Ping timeout: 260 seconds]
<hyper_ch2>
do you have any experience with that?
<srhb>
Using docker?
<hyper_ch2>
yes
<hyper_ch2>
using docker on nixos
<srhb>
There's no particularly declarative way to do it.
<srhb>
kubernetes, for instance, just jury rigs some systemd services to start/stop various docker containers.
<hyper_ch2>
well, I just can't get it to work.. whiel I can live without deskew it would be nice to have it..... or alternatively use the docker option....
<srhb>
hyper_ch2: Sure. docker is essentially the same on NixOS as anywhere else.
<hyper_ch2>
thx though
<srhb>
hyper_ch2: And if you want someone to try their hand at fixing the remaining tests, it would be great if you could provide a commit that gets as far as that. :)
<srhb>
Cloning what you have doesn't get me that at all.
nschoe has joined #nixos
<hyper_ch2>
srhb: I need to update it anyway :)
Itkovian has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<srhb>
Cool. :)
<hyper_ch2>
I didn't commit the tests until I at least could get it to work (without leptonica and hence without deskew)
<hyper_ch2>
srhb: not cool... tried last week and failed miserably :)
<hyper_ch2>
more dependencies were added :(
<srhb>
Eh, that's normal.
<srhb>
It looks like a very complex piece of software, I wouldn't expect to be able to package it in a very short time.
<hyper_ch2>
well, with that nix expression in my repo I was at least able to get rid of abbyy ocr4linux though
<srhb>
I don't know what that means.. :)
<hyper_ch2>
the ocr on ocrmypdf is quite good
<hyper_ch2>
abbyy ocr4linux is what I used before to auto-ocr scanned in documents
<srhb>
Ah
<srhb>
That's nice. :)
<hyper_ch2>
it was the only decent one I could run from the cli that I could find back then
Ariakenom_ is now known as Ariakenom
<hyper_ch2>
srhb: I guess you have no need for ocr
<srhb>
hyper_ch2: Well I might (emphasis might) take a stab at it if you get it in a place where I can get at the test failures in a sandbox build.
<srhb>
Not so far at least
<hyper_ch2>
you never scan in letters and stuff? oO
<srhb>
I get like.. Two or three letters per year, everything else is already electronic.
<hyper_ch2>
srhb: wait until I get it to run on latest version
<srhb>
And those letters are usually just bills or whatever.
<nschoe>
Hi everyone, I'm interested in knowing how you guys manage your nixOS installation: ar eyou using the stable nixos channel? the unstable one? Both? Did you ditch the channel and only use a cloned version of nixpgks?
<srhb>
nschoe: Personally I use a local checkout and switch between unstable and stable a lot.
rprije has quit [Ping timeout: 250 seconds]
Itkovian has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jasongrossman>
nschoe: I use unstable except for the rare occasions when something that I really need in unstable is broken, and then I add that thing using nix-env.
<ben>
I have a python application with a setup.py. What's the right way to generate a .nix file I can install into my nix-env profile?
<hyper_ch2>
nschoe: I use unstable usually
Itkovian_ has joined #nixos
vidbina has joined #nixos
thc202 has quit [Ping timeout: 246 seconds]
<srhb>
ben: There are tools like pip2nix and pypi2nix, of which I don't recall which is the more recent/useful, and also others. however, if the package is not too complicated, I'd probably start by grepping for buildPythonApplication in nixpkgs and try cargo culting an existing expression.
sanitarium has joined #nixos
thc202 has joined #nixos
ThatDocsLady has quit [Ping timeout: 268 seconds]
carlosdagos has quit [Quit: Connection closed for inactivity]
<nschoe>
jasongrossman, hyper_ch2 srhb this means you have "unstable" as a channel, right?
<srhb>
nschoe: No, I have no channels.
<nschoe>
srhb, ho soryr yes, local checkout.
<jasongrossman>
nschoe: I do.
<nschoe>
srhb, so on master?
<hyper_ch2>
nschoe: yes
<nschoe>
jasongrossman, okay. Is your unstable channel added as the regular user or as root? I never know which one is the "right choice".
<srhb>
I have one main checkout that my system uses as its pkgs, and everything else I get via fetchFromGitHub and friends. I'm currently on release-18.09, but will probably switch to nixos-unstable/master soon. The branch I use changes a lot though. I go back and forth.
<nschoe>
srhb, okay I see.
<srhb>
nschoe: You should almost always have no user channels and only root channels, to lessen channel confusion :)
<nschoe>
srhb, how do you keep up what's up-to-date on yoru system? I you change a lot, it must mean you cannot use `nix-env -u`, right?
<srhb>
nschoe: I barely ever use nix-env.
<nschoe>
srhb, ah! Damn I have just setup the exact opposite.
<srhb>
nschoe: Everything is declarative in my system, via configuration.nix
<nschoe>
srhb, really? Is everything in you configuration.nix?
<srhb>
nschoe: Almost. I do use home-manager, which is like configuration.nix for your user.
<srhb>
nschoe: But essentially, yes. I only use ephemeral shell environments and the declarative system.
<nschoe>
srhb, okay, so you're here and "hey I'd like to install Gimp (for instance)", you go edit you configuration.nix and run `nixos-rebuid switch`? Is that it?
<srhb>
nschoe: Yep.
<nschoe>
srhb, okay the only issue with that is that there's no way to "jsut install gimp": by running the nixo-rebuild, you'll update every package in the configuration.nix :/
<srhb>
nschoe: What does "update" mean :)
<srhb>
nschoe: (Meaning, if my git checkout didn't move, nothing gets upgraded)
<nschoe>
srhb, yes, but what if I just want to install Gimp and not update my whole system?
<domenkozar>
gchristensen: yeah, why :)
<srhb>
nschoe: Don't move your branch/channel, and the only change to the new system will be that gimp was added. :)
<nschoe>
srhb, oh right! Cause you're not using channel. Local checkout.
<srhb>
nschoe: Well, same logic applies to channels
<nschoe>
I'm curious about channels then: why won't you use them?
<srhb>
nschoe: I think they're way more confusing and magical than a git checkout. I know git well, so I don't like an abstraction that I have no need for.
<nschoe>
srhb, I see.
<jasongrossman>
nschoe: I install things as root, for the same reason as srhb.
<srhb>
nschoe: Plus the added bonus of easily being able to test a patch and upstream it :)
<nschoe>
srhb, and a stupid question: in the configuration.nix, where does the "pkgs" comes from if you don't have channel> How do you make it "point" to your local nixpkgs?
<nschoe>
jasongrossman, okay, but with nix-env or configuration.nix?
<LnL>
but depending on what revision you check out it might not be tested at all, so it could potentially break your system
<clefru>
I have been trying to figure out which package provides the "gio" command, which gvfs-info requires, which for me at the moment does: /run/current-system/sw/bin/gvfs-info: line 13: exec: gio: not found
<LnL>
I would discourage not using a channel for your base system
<srhb>
fwiw channels are mirrored in the nixpkgs-channels repo as branches, so if you use that, you gain the exact same testedness guarantees.
<clefru>
LnL: a git checkout is much easier to manage for me, but FYMV
<srhb>
,locate bin gio
<{^_^}>
Found in packages: glib.dev
<LnL>
sure, but the distinction isn't that clear
<jasongrossman>
nschoe: configuration.nix, unless I'm in a huge hurry or am just testing stuff that I probably don't want to keep around.
<clefru>
srhb: thank you! glib.dev is a bit counter intuitive though...
apeyroux has quit [Remote host closed the connection]
<srhb>
clefru: I know nothing about it except how to find it. :-P
<jasongrossman>
I might use git more if I knew much about git, as srhb and clefru do. But if in doubt it's best to use channels, because they're better documented.
<clefru>
srhb++ thanks :)
<nschoe>
Thank sall (sorry for the time between my answers: but I do take notes at the same time)
<jasongrossman>
Oh, that's interesting. Apparently incrementing kudos requires a separate line.
<jasongrossman>
srhb++
<{^_^}>
srhb's karma got increased to 23
<srhb>
jsongrossman: That recommendation is probably true. However, despite their supposed documentation, users constantly have problems using them correctly. :-)
<jasongrossman>
srhb: Trudat.
<clefru>
how do I talk to {^_^} in private? it doesn't respond to PRIVMSG help
<srhb>
That said, a beginner to git would probably experience the same.
<nschoe>
LnL, ah now I'm curious: why do you say it's safer to use a nix-channel? Because they are more tested than the git master, right?
<jasongrossman>
nschoe: I was saying it because they're better documented (in the manuals).
<jasongrossman>
nschoe: I'm sure both ways are fine, and if the documentation switched to documenting git more then I'd be fine with that and would switch my recommendation.
<srhb>
clefru: I forget how to get it to list commands, but it will respond to regular queries, eg. "> 42"
<nschoe>
jasongrossman, I see.
<srhb>
nschoe: I would not recommend running master even if you use a git checkout
<srhb>
nschoe: master is, essentially, completely untested.
<jasongrossman>
srhb: That's the first unexpected thing I've heard recently. Why use master?
<jasongrossman>
Oh ha I misread that.
<srhb>
jasongrossman: I think I said the exact opposite :-)(
<srhb>
hah
<jasongrossman>
You did.
<jasongrossman>
jasongrossman--
<nschoe>
jasongrossman, the main "issue" I had/have with channels, is that I see we can add some as regular user (nix-channel --list would list them) or a as root (in which case nix-channel --list would not). And when I use `nix-env` as a user I never know which one it uses.
<srhb>
jasongrossman: Don't worry, you can never lose karma.
<LnL>
yes, you can't checkout a bad revision with channels those only update if certain tests pass
<nschoe>
srhb, ah, good to know. Is there a safer branch then?
<jasongrossman>
srhb: I suspected I couldn't. It's like a confessional. Win-win.
<srhb>
nschoe: That's why I recommended that iff you use channels, only have them as root.
<adisbladis>
nschoe: You can follow the channels with git too
<LnL>
with git you have access to everything in between those good points
<srhb>
nschoe: Every channel has a corresponding branch in one of the repos
<jasongrossman>
I agree. Use channels, as root only.
<nschoe>
LnL, I see
<srhb>
nschoe: For instance, nixpkgs-channels/nixos-18.09
<srhb>
That is the current stable channel, as a git branch.
<srhb>
nschoe: In general as an end user using a git checkout, you'd always use one of the branches from that repo.
<adisbladis>
I would _only_ recommend master if you are hacking on nixpkgs a lot and willing to deal with breakage =)
<srhb>
nschoe: And only the nixpkgs repo when you want to develop on either master or release-18.09 (the latter being the untested variant of nixos-18.09, before promotion to nixpkgs-channels)
<nschoe>
srhb, I see. But then this is essentially the same as running on channels.
<nschoe>
Expect it's on git
<srhb>
Yes.
<nschoe>
Okay so now the situation is not so clear anymore. ^
<srhb>
Haha, okay.
<nschoe>
I mean the informaiton is clear: but I'm not sure what I should/want to do now.
<srhb>
My point was: git is less confusing than channels for SOME users, and provides the exact same features if you use the corresponding -channels branches.
<LnL>
you have more flexibility with git, but also the power to do potentially dangerous things
<srhb>
And that :-)
<nschoe>
LnL, and jasongrossman essentially "saved" the channels for me whe nthey said to use them only as root: no confusion anymore
<jasongrossman>
nschoe: You should use nixos-stable or nixos-unstable, as root, via configuration.nix, unless you particularly enjoy using git.
<jasongrossman>
Right.
<jasongrossman>
Overlapped.
<nschoe>
jasongrossman, all right, but then there is one thing that doesn't make sense: in the manual, its is often advertised than nix/nixOS allows regular users to install packages, without th eneed to be root, like most of the other distros.
<nschoe>
But if the channel is only used as root, the only way to update it, is to run `sudo nix-channel --update`. And it means that we still need root access.
<jasongrossman>
nschoe: My guess is that that's advertising mainly to people who can use Nix but can't use NixOS. Which is many people, because of the current popularity of MacOS.
<nschoe>
srhb, okay I see your point.
<jasongrossman>
nschoe: Having used both Nix and NixOS, I believe Nix is pretty rubbish. NixOS, OTOH, rocks. And yes you want root to use it properly.
<jasongrossman>
nschoe: Just to be clear, regular users CAN and do install packages on NixOS, but it's not my recommended way of doing things when you're starting out.
<ldlework>
kalbasit[m]: nix-env and nix-shell do not use the nixos configuration, so no
<jasongrossman>
nschoe: Maybe this will help. In NixOS, the kernel and other systemy things are packages, so of course you're going to want to use NixOS as root. And if you're doing that then by far the least confusing thing is to use configuration.nix, as root, for other things too.
<nschoe>
jasongrossman, I see. Okay I guess I have it the wrong way then. Up to now I had only the bare minimal in my configuration.nix, the 'system things'. And I installed everything via `nix-env`.
<jasongrossman>
nschoe: Right, so that should work, but it's NOT the least confusing way of doing things.
<srhb>
nschoe: I sympathize with that approach and that's how I started myself
<srhb>
nschoe: If you like having a minimal system like that, I more heartily recommend home-manager
<nschoe>
I guess I'll change all of this. I think I'll go toward the safe version: I'll use the unstable channel (as root!), and switch everything to my configuration.nix (well I will take a look at home-manager, too).
<srhb>
nschoe: That way you can quickly change your system configuration, and leave the heavy userspace changes to home-manager.
<jasongrossman>
nschoe: I think you will have joy.
<adisbladis>
I'm very ambivalent about nix-env
<srhb>
It's possibly to use nix-env more sanely by defining declarative specs to install with it
<srhb>
(Which in essence is what nixos-rebuild does)
<adisbladis>
It's really good for starting out and makes nix a far less radical departure, but I do think it's bad practice to keep using it
<nschoe>
srhb, okay, so configuration.nix + home-manager + nix-channel makes it "safe" + completely declarative, right? So I think I'll go with it.
<jasongrossman>
adisbladis: Me too. I use nix-env quite a lot, but only because I'm impatient, and I move nix-enved things into configuration.nix ASAP.
sigmundv has joined #nixos
<adisbladis>
jasongrossman: Use home-manager as a nixos module :)
<nschoe>
adisbladis, it seems I agree with you, after this conversation.
<adisbladis>
The best of both worlds
<srhb>
nschoe: Yes, aside from the potential discrepancy between when you run nixos-rebuild switch and when you run home-manager switch, but that appears to be a feature you're desiring.
<adisbladis>
srhb: Do you know you can also use it as a nixos module and apply it when you do nixos-rebuild? :)
<adisbladis>
I even deploy home-manager configs with nixops thanks to that <3
<nschoe>
srhb, I was about to ask about the discrepancy betwene the towo precisely. Well I'll read about home-manager. See how it works and then I'll decide if I go full configuration.nix or use the home-manager or not. I initially thought home-manager was about versionning th dotfiles, not installing packages. Maybe I'm not interested in separating the two anymore.
<nschoe>
adisbladis, that's cool.
<nschoe>
Well, everyone, thanks a lot for your help, time and ton of information.
<nschoe>
It might be the first time nix/nixOS is becomming clearer! So
<srhb>
nschoe: It's both: It also gives you the more trivial feature of providing something like "systemPackages" but for your user
<nschoe>
srhb++
<{^_^}>
srhb's karma got increased to 24
<nschoe>
jasongrossman ++
<{^_^}>
jasongrossman's karma got increased to 4
<nschoe>
LnL++
<{^_^}>
LnL's karma got increased to 7
<nschoe>
:)
<srhb>
sweet sweet karmas... :-)
<nschoe>
I have some reading now, thanks again.
<srhb>
Enjoy!
<nschoe>
Yeah ^^ I'll come annoy this chan again when something's not clear ;)
sir_guy_carleton has joined #nixos
<srhb>
We have a pretty high threshold before something becomes annoying. :-P
drakonis_ has quit [Ping timeout: 252 seconds]
fendor has joined #nixos
<adisbladis>
<3 #nixos
drakonis_ has joined #nixos
<nschoe>
srhb, (I have a pretty high capacity to ask finicky questions too ^^)
<jasongrossman>
Yeah, this is a super-friendly channel. (It's why I'm here. I don't even use Nix. No, just kidding.)
nschoe has quit [Read error: Connection reset by peer]
mayhewluke has joined #nixos
<tobiasBora>
I'd like to know: when I start okular from a konsole or from dolphin... I have a "nice" okular, that respects the KDE theme. However, when I start okular from emacs (either by doing "M-: okular", or by using the LaTeX mode that calls okular), I get an ugly okular, that does not respect the KDE theme, and also that seems to have "independant configuration".
<tobiasBora>
sphalerite: hey ! ;)
<tobiasBora>
s/M-:/M-!
<sphalerite>
tobiasBora: that might be because of the env vars set by the GTK wrapping stuff applied to emacs. Not sure though.
<tobiasBora>
sphalerite: Hum... At least the path env looks fine. What else should I try?
<sphalerite>
tobiasBora: cat $(which emacs)
<sphalerite>
:)
<tobiasBora>
sphalerite: interesting, thanks, I'll try to see which env is a problem ;)
<tobiasBora>
sphalerite: Hum, it seems to be more complicated than than
<tobiasBora>
sphalerite: in fact, I realized that if I run emacs manually, okular is nice. the problem appears when I run okular from the daemon-emacs
orivej has joined #nixos
<sphalerite>
fun
<sphalerite>
how do you start the daemon emacs?
revtintin has quit [Quit: WeeChat 1.9.1]
<sir_guy_carleton>
i found that setting XDG_CURRENT_DESTOP=kde got various kde applications to respect kde-theming in i3. maybe that will work?
<sir_guy_carleton>
tobiasBora: like 'exec XDG_CURRENT_DESKTOP=kde okular or something
jasongrossman has quit [Read error: Connection reset by peer]
jasongrossman has joined #nixos
<{^_^}>
[nixpkgs] @ikervagyok opened pull request #48549 → [WIP] X11 updates and refactor → https://git.io/fxu71
<tobiasBora>
sir_guy_carleton: I tried "XDG_CURRENT_DESKTOP=kde okular" and okular looks still bad
<tobiasBora>
sphalerite: I start the daemon emacs from nixos using services.emacs.enable = True;
nschoe has joined #nixos
__monty__ has joined #nixos
<tobiasBora>
and then I connect to the daemon using "emacseditor"
<sphalerite>
tobiasBora: yeah then it'll be because it's running as a systemd user service which isn't supposed to be used for graphical stuff…
<sphalerite>
tobiasBora: I'd consider it a bug in the emacs service module.
<tobiasBora>
sphalerite: well I thought it would run one daemon for each user?
<sphalerite>
tobiasBora: yes, it does. It's still broken, because systemd user services aren't integrated with a session
<tobiasBora>
Then what's the point of providing a nixos daemon if it's not the way to go ? Is it more for servers that do not have desktops environments?
<sphalerite>
tobiasBora: presumably whoever wrote the module didn't know
<sphalerite>
or yes, maybe that. I'd guess not knowing is more likely
<sphalerite>
Or knowing and doing it anyway :p
simukis has joined #nixos
rprije has joined #nixos
<tobiasBora>
sphalerite: and is it possible to configure xdg autostart from nix directly, or I need to manually add it in the configuration? Also, is it supposed to be supported by all graphical environment, or all system has it's own way to specify autostart apps?
<nschoe>
Hey, it's me again. I have just an easy question regarding channels and configuration.nix: if I had two channels (the stable one, name "nixos" and the unstable one, named "unstable", (as root)). When I run `nixos-rebuild`, where will it take the packages? From "unstable" or "nixos"? And why? What if my two channels were named "foo" and "bar"? is there smth special about the name "nixos" for a channel?
<sphalerite>
tobiasBora: as far as I can see there's no module for it but you can do it by just putting desktop files in /etc/xdg/autostart using environment.etc
<sphalerite>
tobiasBora: they're run automatically by all "full-featured" desktops like GNOME and Plasma, for lightweight setup you'll need to use something else to run them automatically — just a minute…
<adisbladis>
nschoe: In the end it's down to whats in your NIX_PATH environment variable
<adisbladis>
By default that's pointing to the location of the channel named "nixos" iirc
<nschoe>
adisbladis, oh I see.
<sphalerite>
nschoe: what it uses is nixpkgs from NIX_PATH
<tobiasBora>
sphalerite: thank you for the link, very interesting!
<adisbladis>
Admittedly the UX on this front is not great..
typeggzero has left #nixos [#nixos]
<nschoe>
adisbladis, so it **is** safe to have both channels "nixos" and "unstable" and it will only install / upgrade packages from "nixos" and I can keep "unstable" so that I can use `<unstable>` when/if I need to go bleeding edge, right?
<adisbladis>
nschoe: Yep =)
<nschoe>
sphalerite, provided the NIX_PATH does refer to "nixos".
* colemickens
actually figured out a tricky python thing.
<colemickens>
nixpkgs exposed what looks like a bug in urllib3. kinda surprised
<gchristensen>
domenkozar: haven't quite figured the no-hastle part out, but it isn't complicated. echo -n 1 | sudo tee /sys/bus/thunderbolt/devices/0-1/authorized; echo -n 1 | sudo tee /sys/bus/thunderbolt/devices/0-301/authorized
<sphalerite>
gchristensen: there's also nixpkgs.thunderbolt, not sure what role it plays exactly but it's probably less clunky than writing to sysfs manually
<sphalerite>
weird packaging though, it has a bin output which doesn't have a /bin in it, but out has /bin
<Synthetica>
sphalerite:
<sphalerite>
I can't test it myself, not on a laptop with thunderbolt just now
<Synthetica>
Thanks, defs gonna set that up
<Synthetica>
I am, I can test next week
<sphalerite>
nor do I have any thunderbolt devices, actually
Itkovian has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<gchristensen>
sphalerite: I already made a thing to authorize the device, though, if the uuid and key match X)
Itkovian has joined #nixos
<lassulus>
samueldr: for some weird reason, xpra runs if I connect to an root user (he can start the X server, other users fail with different errors, depending on permissions on /dev/tty0 /dev/tty2 /dev/dri/card0). I will keep working on it.
Itkovian has quit [Client Quit]
emmanuelrosa has joined #nixos
Diagon has joined #nixos
Itkovian has joined #nixos
<{^_^}>
[nixpkgs] @Synthetica9 closed pull request #41627 → [WIP/RFC] make-derivation: default name if pname and version are both set → https://git.io/vhufk
<Synthetica>
On which note, could someone take a look at https://github.com/NixOS/rfcs/pull/35 ? It's been a while since it has received any attention, and I wonder if everything there is to say has been said yet.
<tobiasBora>
I'm wondering, in my debian install I've a menu in Dolphin that let me compress/extract archives
<tobiasBora>
However in nixos I don't know why but this menu does not appear
<tobiasBora>
Did I miss a dependency, or is it a known (or not) bug?
<hyper_ch2>
ark is installed? I think ark is the compressin tool that dolphin uses
<tobiasBora>
hyper_ch2: maybe not, let me try to install it, thanks
<hyper_ch2>
I assumed it would be part of default kde install.... but might be mistaken
<tobiasBora>
Also, is it possible to install in one shot all the depends that kde-full (in debian) has?
<tobiasBora>
because the default KDE install has basically no packages... As it, I don't even have tools like killall, spectacle (for screenshots)... Is there a way to install a full KDE?
<{^_^}>
[nixpkgs] @tilpner opened pull request #48559 → appimage-run: Fix type-1 support, used wrong directory → https://git.io/fxzfW
<tobiasBora>
hyper_ch2: Because I guess most people would like to be able to setup a full system without manually adding every single software inside. Like when I install a desktop like KDE, I'd expect to have at least a tool to make screenshots available by default.
<hyper_ch2>
tobiasBora: feel free to submit a patch for kde full :)
<gchristensen>
tobiasBora: "any reason" -> probably no specific reason
<hyper_ch2>
tobiasBora: I tend to think most people don't want a full system setup when they use nixos... nixos offers granular options for setting up the system and just installing everything in bulk seems contra intuitive
<hyper_ch2>
also, adding every single package is no problem because when you re-deploy the system, you'll just use the existing configuration.nix and bang, you've got it setup the same again
<kreisys>
Has the setting 'allowed-uris' been removed from nix.conf? I upgraded a server to NixOS 18.09 by changing its NixOS channel and now every time I run `nixos-rebuild switch` I'm getting `warning: unknown setting 'allowed-uris'`
<kreisys>
Looking through the release notes and searching through github I don't see any mention of it being removed :confused:
dvim has quit [Read error: Connection reset by peer]
<kreisys>
I get this warning between 'building Nix...' and 'building the system configuration...' msgs
<rawtaz>
kreisys: please pastebin the complete rebuild command and all of its output when you run it WITH --show-trace (or similar, might wanna check the manual to be sure thats the name of the argument)
<kreisys>
--show-trace makes no difference since there's no error, only a warning
dvim has joined #nixos
<rawtaz>
ok, then it doesnt hurt to include it in your run, i presume?
<rawtaz>
which is the file that the option description gchristensen linked to
<gchristensen>
rawtaz: you can specify allowed-uris in the extraOptions option.
<arianvp>
anyone here experience with packaging ruby?
<arianvp>
I followed the guide, but in the nix-shell it cant find dependencies
astronavt has quit [Ping timeout: 246 seconds]
<rawtaz>
gchristensen: right but if that option cannot be found in the file that the option description references, then why should be expect the option to exist/have any effect?
<kreisys>
Lol I'm relieved that this is actually a thing because I was sure that I'm just being stupid.
Tucky has joined #nixos
<kreisys>
I'm curious what would happen if I nuke all the config except for nix.extraConfig
<gchristensen>
okay! I think we found a bug! I think you can ignore it for now
<gchristensen>
nix-store is the only command I've found which is unhappy with the allowed-uris setting, and I can replicate your issue. but I can't replicate the issue with nix-env, `nix`, or `nix-build`
<tobiasBora>
and for the "download and run archive", I've another problem: sage crashes at startup with an error "/home/me/SageMath_8.3/build/bin/sage-python23: ligne 31: /home/me/SageMath_8.3/local/bin/python2: No such file or directory"
endformationage has joined #nixos
<tobiasBora>
while of this file do exist
<tobiasBora>
so I guess it's a problem of interpreter
<asymmetric>
hey, has anyone gotten font-awesome fonts working on nixos? i have `fonts.fonts = with pkgs; [ font-awesome_5 ] but they still don't show in vim
fendor has quit [Ping timeout: 252 seconds]
justbeingglad has quit [Quit: Leaving.]
<tobiasBora>
I tried to replace the files here with a link to the system's python... but then I've errors like "ImportError: No module named sage.misc.banner
reinzelmann has quit [Quit: Leaving]
<tobiasBora>
(I guess that the python executable contains some loaded libraries...)
<tobiasBora>
any solution?
dongcarl has joined #nixos
<dongcarl>
Hi all! Just got on Nix... I know that I'm not supposed to touch my `hardware-configuration.nix`, but I'm wondering what's the most idiomatic way to override my `fileSystems."/"` in my `configuration.nix`.
<Synthetica>
Re-mount it manually and re-run nixos-generate-config
<dongcarl>
Just setting it using `fileSystems."/" = { ... }` gives me errors saying there are duplicate things set
<dongcarl>
Synthetica: I wanted to refer to "/" and my swap by label, which is why I'm asking
<dongcarl>
`hardware-configuration.nix` seems to want to do it by UUID
<Synthetica>
Why, if I may ask?
<joko>
Hey, is it possible to reset manually my nix channel cache? nixexprs.tar.xz seems to be cached
<dongcarl>
Synthetica: well because I just want to... and I like exploring the boundaries of a system especially when I've heard so many good things about it haha
<dongcarl>
I know I can do `pkgs.lib.mkForce`, but that seems un-idiomatic
orivej has quit [Quit: No Ping reply in 180 seconds.]
<etu>
dongcarl: I control my files with git, I tend to do some modifications to the hardware one even though the comments tell me not to. But yeah, if I do a nixos-generate-config it sometimes diff ant destroy things for me. That's the risk more or less.
<exarkun1>
What's best practice for referring to ca-bundle.crt in a config file for a service? ${pkgs.cacert}/etc/ssl/certs/ca-bundle.crt or /etc/ssl/certs/ca-bundle.crt? Why?
Itkovian has joined #nixos
Itkovian has quit [Client Quit]
<lassulus>
imho /etc/ssl/certs/ca-bundle.crt, because otherwise certificates from the options security.pki.certificateFiles/security.pki.certificates get ignored.
drakonis has joined #nixos
<exarkun1>
Ah, interesting point. I didn't really know about `security.pki` before. Should I worry about pkgs.cacert accidentally not being installed? Should I declare a dependency on it in some other way? Does using the `${pkgs.cacert}/...` form even make any difference from that angle?
<lassulus>
well the default of security.pki.certificateFiles does already include ${pkgs.cacert} so I don't think it will be missing on a normal installation. Only if the user wanted to remove it explicitly
<lassulus>
and then it would be somehow sneaky to reintroduce the certificates ;D
<worldofpeace>
In what unit does `nix path-info -S` print the size of the path?
jtojnar has quit [Remote host closed the connection]
<sphalerite>
worldofpeace: bytes
<worldofpeace>
yay
<exarkun1>
lassulus (IRC): alright, thanks!
<cransom>
gchristensen: re: juniper nixops. not really. it's been a few years since i've been paid to junos so it hasn't been at the front of my mind.
* gchristensen
was hoping to nerd-snipe
Baughn has joined #nixos
ryantrinkle has joined #nixos
<jabranham>
I'm trying to write an overlay to use a different source for a package. I also want to change one of the package options in nixpkgs. I can get the former to work with overrideAttrs but I can't seem to specify arg = newval for the second?
Baughn has quit [Client Quit]
Baughn has joined #nixos
<Synthetica>
X: Is there a way to check if a value is used anywhere?
<Synthetica>
Y: is there a way to raise a warning if a value is not used anywhere?
<sphalerite>
jabranham: to override package args, use override
<Synthetica>
(raise a warning, or trace a message, or whatever)
<symphorien>
X: builtins.trace
<jabranham>
sphalerite: so I have to use override for the arg and overrideAttrs for the src?
<sphalerite>
jabranham: yep
<sphalerite>
jabranham: I think the order doesn't matter, but you do need to parenthesise as appropriate
johanot has quit [Quit: WeeChat 2.2]
<sphalerite>
Synthetica: not really, because lazy evaluation => if a value isn't used it isn't even evaluated
<Synthetica>
Hmm, so it'd require a change to the nix interpreter?
Itkovian has joined #nixos
<sphalerite>
Synthetica: quite possibly some pretty fundamental language changes even.
<sphalerite>
Synthetica: what's the W in here? ;)
<Synthetica>
I have a few definitions on top of my configuration.nix that I'd like to see a warning for if I don't use them anywhere, because they involve a fetchUrl
EarlDeLaWarr has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Itkovian has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Itkovian has joined #nixos
Tucky has quit [Quit: WeeChat 2.2]
EarlDeLaWarr has joined #nixos
<exarkun1>
did you note the comment above about unused values not being evaluated?
<Synthetica>
exarkun1: I suppose it isn't that much of a problem, but they mostly are temporary fixes and I tend to forget to remove them when I don't use them anymore
hyper_ch2 has quit [Quit: Page closed]
ryantrinkle has quit [Ping timeout: 245 seconds]
gmarmstrong has joined #nixos
<exarkun1>
There could probably be a linter of some sort of that kind of thing.
<{^_^}>
[nixpkgs] @rbvermaa pushed to release-18.09 « blivet: fix reference to selinux python modules »: https://git.io/fxzRy
<{^_^}>
[nixpkgs] @rbvermaa pushed to master « blivet: fix reference to selinux python modules »: https://git.io/fxzRH
<betaboon>
is anyone using uwsgi with pythonapps ?
<betaboon>
I'm somewhat stuck at "ModuleNotFoundError: No module named 'pkg_resources'"... which i just cant understand how that even happens
<arianvp>
dlopen /nix/store/picsldd7p8gc6rgpaxahjs5xrpz63lzg-yubico-piv-tool-1.6.1/lib/libykcs11.so failed: /nix/store/fg4yq8i8wd08xg3fy58l6q73cjy8hjr2-glibc-2.27/lib/libpthread.so.0: symbol __sigtimedwait, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
<arianvp>
im getting errors in glibc when it's trying to figure out my ssh key
<jabranham>
OK, I think I got that overlay working. Here's what I ended up with in case anyone is interested. https://gitlab.com/snippets/1764400
<exarkun1>
What's the difference between `environment.packages = [ X, depOfX ]` and `environment.packages = [ X ]` combined with `x.propagatedBuildInputs = [ depOfX ]`?
ThatDocsLady has quit [Ping timeout: 244 seconds]
gmarmstrong has quit [Quit: Quit]
<infinisil>
exarkun1: the first will be a syntax error :)
<infinisil>
And the second won't result in depOfX being in systemPackages
<infinisil>
It's a *build* input, build inputs don
<infinisil>
't get propagated to the outputs themselves
<exarkun1>
infinisil (IRC): what is "propagated" about "propagatedBuildInputs"?
* exarkun1
re-reads the docs for the 12th time
<exarkun1>
okay they only propagate as build inputs to downstream packages
<exarkun1>
not to installation environment
<infinisil>
It being a build input. I think it goes like this: If you have a.buildInput = b; and b.propBuildInput = c; then c will also be a buildInput of a.
<infinisil>
Nothing to do with what gets installed
<exarkun1>
where's the slot for runtime dependencies?
<infinisil>
There is propagatedUserEnvPackages or something like that which you could use, but it's usually discouraged
<infinisil>
And runtime deps is something else too
<infinisil>
,runtimeDeps
<{^_^}>
In order of preference: Patch source OR ((if it uses PATH -> wrap with new $PATH) AND (if it uses dlopen, (patchelf --set-rpath in postFixup OR wrap with new LD_LIBRARY_PATH)))
nikivi has quit [Quit: ZNC is awesome]
<infinisil>
exarkun1: if you have a specific problem to solve it's best to just describe the problem
<{^_^}>
[nixpkgs] @xeji pushed commit from @volth to master « varnish4: 4.1.9 -> 4.1.10 (#48488) »: https://git.io/fxzai
<exarkun1>
Okay. Specific problem. Zcash has a runtime dependency on wget and flock. Currently I have all three in `environment.packages` but I'd rather fix the Zcash definition so that including only Zcash in `environment.packages` results in a working system
<clever>
exarkun1: `Patch source OR ((if it uses PATH -> wrap with new $PATH)`
<infinisil>
I guess it's not exactly what you need, but there's a wrapProgram/makeWrapper example there too
simukis has joined #nixos
<exarkun1>
Okay. I see some wrapProgram docs. I think I get it.
<betaboon>
i am having trouble setting up uwsgi with python3 applications. when uwsgi is starting the application, after adding the proper pythonpath, the application cannot find the pkg_resources module. I'm realy out of ideas here :(
astronavt has joined #nixos
justanotheruser has quit [Ping timeout: 272 seconds]
<{^_^}>
[nixpkgs] @bnikolic opened pull request #48575 → magit-filenotify: Fix missing dependency on git → https://git.io/fxzwe
fendor has quit [Ping timeout: 268 seconds]
astronavt_ has joined #nixos
<infinisil>
betaboon: That's a bit too little information to be of any use for debugging for anybody wanting to help you..
<betaboon>
infinisil: just trying to compile an example that i can share
shymega has left #nixos [#nixos]
nikivi has joined #nixos
<sphalerite>
betaboon: my best guess would be that you're using uwsgi as its own package, and bin/uwsgi is a wrapper which overrides the pythonpath thatyou set
<{^_^}>
[nixpkgs] @xeji pushed commit from @r-ryantm to master « googler: 3.7 -> 3.7.1 (#48508) »: https://git.io/fxzrx
simukis has joined #nixos
simukis has quit [Client Quit]
<mokasin>
nixpkgs.overlays = [(self: super: { nextcloud = unstable.nextcloud; })]; where unstable refers to nixos-unstable channel does not seem to work
<mokasin>
How do I override a package? I managed to override the corresponding module
<sphalerite>
betaboon: oh hm. maybe (just a shot in the dark) you need to add pip to pythoNPackages
simukis has joined #nixos
<mokasin>
The documentation of overlay in the manual just confuses me more. Can somebody point me to a document explaining overlays?
<betaboon>
LnL sphalerite : just figured out: if i set the pythonpath via instance.env = ["PYTHONPATH=....."] to the path of the pyEnv in the nix-store explicitly it can find the module
halfbit has quit [Ping timeout: 252 seconds]
<LnL>
betaboon: that's more of a workaround, like I mentioned on the issue the plugin part is important
lostman has quit [Quit: Connection closed for inactivity]
<exarkun1>
Re-compiling unchanged sources because of non-compile-related derivation changes takes too long. How do I spend less time doing this?
<betaboon>
LnL: even with the plugin= part it doesnt seem to work
<sphalerite>
exarkun1: how is the derivation changing?
kreisys has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
worldofpeace has joined #nixos
Thra11 has joined #nixos
<exarkun1>
sphalerite (IRC): eg postBuild
orivej has quit [Quit: No Ping reply in 180 seconds.]
<sphalerite>
exarkun1: not much to be done really if you want clean builds. You could use nix-shell for testing though.
<exarkun1>
not sure what "clean builds" means exactly seems like a waste to recompile all of this C++ to .o though.
orivej has joined #nixos
civodul has quit [Quit: ERC (IRC client for Emacs 26.1)]
<sphalerite>
exarkun1: you can do some extremely nasty hacks like importing a source tree with already done builds, then touching all the .o files, but it's really nasty :)
lord| has quit [Ping timeout: 246 seconds]
<sphalerite>
exarkun1: you could also create one drv to build the .os and use it as an input to the next. But you can't split up a single drv into parts properly
<sphalerite>
again, probably the best thing to do is just use nix-shell
<sphalerite>
I suppose it also depends on what you're actually doing in postBuild
<maurer>
I feel like I should remember how, but don't - how do I preint out what packages depend on a store path?
halfbit has joined #nixos
<exarkun1>
What about this ccache thing?
<maurer>
Found it myself. In case anyone finds irc logs searching for same question, answer is
<betaboon>
LnL: and even tho the pythonpath is set within the vassals-json-config, the PYTHONPATH is empty when trying to read it in wsgi.py
<__monty__>
Maybe it's not exported?
alex`` has joined #nixos
<neonfuz>
Hey, trying to write a nix package, how do I pass additional cmake flags?
<neonfuz>
I tried cmakeFlags = [ "flags" ]
<neonfuz>
maybe it's just a string?
<clever>
lists turn into a space seperated string when used in a derivation
<LnL>
betaboon: is this the application or dependencies?
<betaboon>
LnL: the module not being found ?
<LnL>
betaboon: for dependencies you'll want to sure a python interpreter using python.withPackages
<LnL>
yeah
<mokasin>
When removing a declarative container from configuration.nix, there is a stale /var/lib/containername folder, that I cannot remove? How do I get rid of it?
<neonfuz>
omg I'm dumb, I was editing a copy of my nix expression
<betaboon>
LnL: the application is being found. and uwsgi tries to start it. the module that is not being found is a dependency (the module pkg_resources which is part of setuptools)
<hodapp>
what updates typically make it to a released version, versus just master?
<betaboon>
LnL: which results in None. which confuses me, as i was under the impressions that the vassals-config.json->pythonpath would result in it being exported
<betaboon>
this is just confusing
<LnL>
betaboon: what about if you nix-build my_flask_app and run nix-store -qR on the result?
<mokasin>
There seems to be an issue with the virtual network device if the container name is longer than 11 characters. Because given a container with name abcdefghijkl the device is show in ip link truncated as ve-abcdefghjk
<mokasin>
But systemd looks for a device named ce-abcdefghijkL
<mokasin>
So it fails
<betaboon>
LnL: it does include setuptools. and it is even in the generated pythonpath, that uwsgi claims to add.
mekeor has quit [Remote host closed the connection]
<betaboon>
LnL: another interesting thing: the python-envs-path is in sys.path... still the import cant find it. wtf
grp has joined #nixos
dvim has quit [Ping timeout: 272 seconds]
<azazel>
hey guys, if development environment that's using nix-shell needs a service like postgres or nginx, what's the best way to deal with it? Build a VM and run all inside it? Or there's a way to install a service....locally?
<Yaniel>
in nix-shell?
<hodapp>
there are containers
<hodapp>
but... that's not really a nix-shell-able thing
<infinisil>
azazel: You can extract the nginx command from a nixos config
<fendor>
can teamviewer run on nixos? i installed it via nix-env and i enabled the teamviewer daemon, but when i open the gui, the client can not connect to any host, hence, i can not access any other pc. no error message though
astronavt has quit [Remote host closed the connection]
<clever>
fendor: they upgrade things in a breaking fasion regularly
<fendor>
clever, :/
<fendor>
how do the other distros handle it?
nschoe has joined #nixos
<clever>
fendor: i think part of it is that nixos tends to just be less compatible, due to things like no /lib and such
<clever>
fendor: and teamsviewer just outright disabling the old versions the instant a new one comes out
<fendor>
hmpf...
<fendor>
well, supporting a solution such as flatpack or snap would kinda solve that problem, right?
jbgi has quit [Quit: WeeChat 2.2]
genesis has quit [Remote host closed the connection]
<goibhniu>
maybe you can run a binary via steam-run?
<Synthetica>
fendor: Possibly, I could see something like `derivationFromFlatpack` being a thing
<hodapp>
one of these days I should learn what Flatpack and Snap are
<fendor>
Synthetica, it would be fine if you could just install it it via flatpack as well, but i think there is an according ticket already
<fendor>
hodapp, in principle, a unified package manager that should work across all linux os's. Snap being from canonical and flatpack from somewhere else, competing with each other and ultimately defeating the purpose of either of them
orivej has quit [Ping timeout: 252 seconds]
<fiatjaf>
I was developing a project with haskell with nix (not nixos), then as I was reading the manual I decided to try out `nix-store --gc`
jabranham has joined #nixos
orivej has joined #nixos
<fiatjaf>
all the builds my project dependended on were deleted
<fiatjaf>
why?
<elvishjerricco>
fiatjaf: ... what did you think would happen? :P The gc's job is to delete anything without a root
<hodapp>
fendor: huh, I see
mutlu has joined #nixos
nbardiuk has joined #nixos
<fendor>
hodapp, that would make it trivial to install software on any linux, hence, making it easy for software developers to deploy their software. However, typical linux schism happened
<fendor>
fun fact, i just never realized i wrote flatpak wrong, therefore didnt find it in the packages although it is there!
<fiatjaf>
elvishjerricco, so how can I delete everything that isn't being used by any of my projects?
<elvishjerricco>
fiatjaf: Just make GC roots to your project's results. nix-build does this automatically, though nix-shell does not
<fiatjaf>
elvishjerricco, I was using nix-build
<fiatjaf>
where should these roots be?
<elvishjerricco>
fiatjaf: Were you deleting the symlink nix-build created in the working dir? Because that symlink *is* the GC root
<cocreature>
nix-build will make a gc root for your runtime dependencies, not for your build dependencies
phreedom has quit [Ping timeout: 256 seconds]
<elvishjerricco>
cocreature: With haskell stuff those are usually the same thing
<elvishjerricco>
since it's dynamically linked by default
<cocreature>
only if you also have a library and you haven’t used justStaticExecutables
<elvishjerricco>
Right, but by default, any haskell derivation, library or executable, will be dynamically linked.
<fiatjaf>
hahah, yeah I was
<exarkun1>
I don't understand wrapProgram. The docs say it takes an executable as its first argument but it rejects such an argument: `Builder called die: makeWrapper doesn't understand the arg zcutil/fetch-params.sh`
<fiatjaf>
but how does nix know where the roots are?
<cocreature>
elvishjerricco: you sure about that? I recall that last I checked executable-only packages were linked statically by default
<elvishjerricco>
fiatjaf: To keep build time dependencies, set `keep-outputs = true` in /etc/nix/nix.conf, or just pass `--keep-outputs` when you invoke the GC
<fiatjaf>
if they are in an arbitrary directory I've created for my project
<elvishjerricco>
fiatjaf: /nix/var/nix/gcroots
<elvishjerricco>
Any symlink in there is followed recursively to find roots
<elvishjerricco>
The root that nix-build creates in your project is symlinked in that directory
<fiatjaf>
is it /etc/nix/nix.conf or /etc/nix/config.nix?
<symphorien>
ah already said
<elvishjerricco>
/etc/nix/nix.conf if you're not on NixOS
<neonfuz>
a nix expression I'm writing is getting a syntax error, invalid final }, but only when I have my meta block included...
<fiatjaf>
but the contents of that is a nix expression?
<neonfuz>
I looked over the syntax and it's identical to toher package's meta blocks
<fiatjaf>
so it should be `{ keep-outputs = true }`?
<elvishjerricco>
fiatjaf: No, nix.conf is a conf file.
<gchristensen>
let's see it, fiatjaf :)
<gchristensen>
oops, neonfuz ^
<elvishjerricco>
Not a nix expression
<symphorien>
just key value pairs
<fiatjaf>
ok
<neonfuz>
anyone have a recommended pastebin?
<cocreature>
elvishjerricco: looking at the source of justStaticExecutables it still just sets isLibrary to false so afaik my statement that for an executable-only package you won’t end up depending on build inputs is still correct
<neonfuz>
is there a nix compatible one? (syntax highlighting)
<gchristensen>
I like gist.github.com
<neonfuz>
oh yeah, sure
<elvishjerricco>
cocreature: Huh.... I was pretty sure I've observed differently. I guess not
<elvishjerricco>
cocreature: Wait no
<cocreature>
elvishjerricco: I think it changed at some point (although that point was at least a few months ago)
<neonfuz>
can someone explain this type of semicolon usage^
<neonfuz>
like what does semicolon actually mean
<neonfuz>
is it an infix operator of something?
<elvishjerricco>
cocreature: Looks like you're right. ldd on a random haskell exe shows no haskell deps. Huh
<symphorien>
let's say it is the end delimiter of with
<elvishjerricco>
cocreature: Why don't we do shared executables by default? We usually have the libraries anyway, and it'd save disk space for basically free
<clever>
elvishjerricco: the dynamic libraries for haskell depend on a file in the ghc storepath
<clever>
elvishjerricco: and that adds 1gig to your closure
<elvishjerricco>
clever: Ah, that makes sense
<elvishjerricco>
clever: Can we not make the GHC libs statically linked as well?
<clever>
i believe the current infra will generate both dynamic and static libs
<elvishjerricco>
oh derp
<elvishjerricco>
eya
<elvishjerricco>
yea
<clever>
and then at link-time for the executable, you pick one
<neonfuz>
I think this is working, should have doom64ex PR coming later tonight when I have time to write up one
<clever>
elvishjerricco: another more painful problem
<clever>
elvishjerricco: the data, and dyn lib, are now in seperate outputs, for all haskell packages
<clever>
so if a package refers to its own data, it wont depend on that 1.6gig monster of a compiler
<clever>
__monty__: i think the root cause, is that every single .hs file in the boot packages (ghc, cabal, base, template-haskell, ghc-prim, containers, and others), is its own .a file, and _p.a
<elvishjerricco>
clever: Ah. So previously, even a statically linked exe would have a runtime dep on the lib (and therefore GHC) just because the lib used its data dir?
<clever>
elvishjerricco: yep
<clever>
elvishjerricco: so js-jquery, whose only point is to give you a 50kb file, pulls in 1.6gig of compiler
<__monty__>
And .a/_p.a files are? (I apologize for my ignorance.)
<clever>
__monty__: the .a files are for static linking, and _p.a are variants of the same with ghc profling enabled
<__monty__>
And .hs files do triple duty for this?
<clever>
it has to compile a profiled and non-profiled version of each i think
<clever>
-r-xr-xr-x 1 root root 72M Dec 31 1969 libHSghc-8.2.2-ghc8.2.2.so
<clever>
-r--r--r-- 1 root root 113M Dec 31 1969 libHSghc-8.2.2.a
<clever>
-r--r--r-- 1 root root 193M Dec 31 1969 libHSghc-8.2.2_p.a
<clever>
just the ghc library itself is over 200mb for the compiled output
<__monty__>
But don't you just need a single copy of these files?
<clever>
you need the .so if you are going to make a dynamic executable
<clever>
and you need the .a if you are making a static executable
<clever>
and the _p.a if you want a static with profiling
<elvishjerricco>
clever: You said: "every single .hs file in the boot packages ... is its own .a file, and _p.a". Did you mean every core lib? I don't think it's an entire archive file per haskell module, I think it's per lib.
<clever>
-r--r--r-- 1 root root 2.3M Dec 31 1969 DynFlags.hi
<clever>
-r--r--r-- 1 root root 2.3M Dec 31 1969 DynFlags.p_hi
<clever>
-r--r--r-- 1 root root 2.3M Dec 31 1969 DynFlags.dyn_hi
<elvishjerricco>
Those are hi files
<clever>
elvishjerricco: yeah, its actually a .hi per file
<elvishjerricco>
I guess hi files aren't exactly small though :P
<clever>
and they are only needed at compile time
<clever>
idealy, we could split the profiled, non-profiled, dynamic, static, and hi files, each into their own outputs
<elvishjerricco>
clever: Hm maybe there should be a way to keep those in a different output?
<elvishjerricco>
Yea
<elvishjerricco>
That'd be sweet
fendor has quit [Ping timeout: 276 seconds]
<{^_^}>
[nixpkgs] @akavel opened pull request #48585 → ocamlPackages.zmq: init at 20180726 → https://git.io/fxzjh
phreedom has joined #nixos
<__monty__>
clever: Wouldn't every haskell executable using the same ghc version be able to use one and the same set of files though? I don't see why it having all necessary types is a big issue. You'd likely end up with two of them on your system at least, no?
<clever>
__monty__: a bigger pain, is when you go to deploy those binaries with nixops
<clever>
the entire 1.6gig of compiler becomes a runtime dep
<clever>
and you have to upload the entire thing to every machine in your cluster
<elvishjerricco>
__monty__: It takes a loooot of haskell exes to save any space by sharing the ghc libs.
lunik1 has joined #nixos
<__monty__>
clever: Ah, yes, sounds painful for specialized servers.
civodul has joined #nixos
<__monty__>
elvishjerricco: It does? Sounds to me like 2'd halve the apparent space usage.
<__monty__>
clever: And could you rehash why even for static executables it is a runtime dep?
<elvishjerricco>
__monty__: With totally static linking, most haskell exes are in single digit megabytes
<clever>
__monty__: when using static linking, ghc can also do dead code elimination, and just omit code your not using
<elvishjerricco>
Meaning it'd take like a hundred exes to even match just the size of GHC
<NickHu>
Does anyone have know of any simple qt5 applications that are packaged that I can use as a template to make a new package?
<clever>
__monty__: with the modern nixpkgs, a static haskell binary wont depend on ghc
<__monty__>
elvishjerricco: But that presupposes completely static builds.
revtintin has quit [Quit: WeeChat 2.1]
<elvishjerricco>
__monty__: Yea. Like they are now
<elvishjerricco>
Except for system libs like glibc
<clever>
yeah, its currently partially static
<clever>
all haskell code is static, everything else is dynamic
<__monty__>
elvishjerricco: Then what was your question about shared executables? I think I took a wrong turn at that point in the discussion.
<elvishjerricco>
I think I originally asked why we don't dynamically link our exes to save space. clever pointed out that it would require keeping the entire GHC derivation in the closure, which is so big that it dwarfs any space savings until you get a pretty massive number of haskell exes
<__monty__>
Ah. Wouldn't it also preclude inlining? Thereby massively undercutting performance?
<elvishjerricco>
__monty__: Nope. Inlining works with static linking.
<elvishjerricco>
It's risky because if the dynamic lib changes, then anything linked against it has to be recompiled
<clever>
i think inlining is why the .hi files are so big
<elvishjerricco>
But Nix already does that
<clever>
a copy of the partially compiled code is in the .hi file
<clever>
so even with dynamic linking, it can "staticly" inline chunks of things
<elvishjerricco>
Whoops, I said it works with static linking. I meant to say both static an dynamic
<clever>
and further optimize what it does inline
<__monty__>
Wow, thanks for the discussion gentlemen. I think I finally have a good grasp of the arch/haskell issues now.
<elvishjerricco>
Yea, so if the lib ever changes at a binary / ABI level, then this can cause code that depends on it to be inconsistent, which would lead to hopefully linker errors but potentially nonsense runtime behavior. So Nix's behavior of require recompilation is required
<clever>
i believe the .hi file encodes both the types of the exported symbols, and the bytecode for in-lineable functions
<clever>
so some methods have 4 copies, .hi, .so, .a, _p.a
<elvishjerricco>
clever: Yes, but if that changes, and you don't recompile dependents, you have a problem
<{^_^}>
[nixpkgs] @rbvermaa pushed to release-18.09 « julia_10: update to 1.0.1 »: https://git.io/fxgvy
<clever>
the design of nix forces a rebuild if the inputs change in any way
<elvishjerricco>
__monty__: This leads to an actual problem with Nix btw. If A depends on B, you build B locally, then fetch A from a binary cache, it's extremely likely that they'll be binary incompatible and you'll get linker or runtime errors
<{^_^}>
[nixpkgs] @rbvermaa pushed to master « julia_10: update to 1.0.1 »: https://git.io/fxgvQ
<elvishjerricco>
clever: Except in the instance I just described
drakonis_ has quit [Ping timeout: 244 seconds]
<clever>
yeah
<elvishjerricco>
Because GHC is nondeterministic
<elvishjerricco>
Because that makes sense for a purely functional language, right? :P
<gchristensen>
how did they manage that? :)
<clever>
your castle of purity is built upon impurities :P
dejanr has joined #nixos
<elvishjerricco>
Reproducible GHC is definitely in my top 5 wishes for Haskell as a whole.
<gchristensen>
that was a serious question,, what are they doing to be impure?
rprije has quit [Remote host closed the connection]
<elvishjerricco>
gchristensen: No idea, honestly. I think a lot of the nondeterminism is in its unique name generator or something? But the IIRC the optimizer is impure as well, and can produce binary incompatible code. No idea why
rprije has joined #nixos
<elvishjerricco>
There was a project that at least got the hi files to be deterministic a while back, which is a major part of fixing all this, but I think it languished
drakonis_ has joined #nixos
realrokka has joined #nixos
<clever>
elvishjerricco: related, ive recently been working on snack, and i found some edge-cases it cant deal with currently
<__monty__>
Is it because nondeterministic algorithms can have sweet complexities?
<clever>
elvishjerricco: under an impure cabal build, ghc can detect when the types exported by a module dont change, and then not rebuild all dependants
<clever>
elvishjerricco: but with nix (and snack), it cant understand that something has changed or not, since it has no way of knowing the previous state
<elvishjerricco>
__monty__: Possibly :)
fendor has joined #nixos
rembo10 has quit [Remote host closed the connection]
<clever>
elvishjerricco: all it knows is that the INPUTS have changed, so all dependants must build!
<elvishjerricco>
clever: Yea, I'm not hopeful for proper incremental Nix+Haskell TBH
<clever>
recursive nix would solve everything
<elvishjerricco>
Doubt it
<clever>
if you just replace ghc with a wrapper, that feeds the .hs and .hi files into nix-build
<elvishjerricco>
invoking Nix on a module can take just as long as compiling the module
<clever>
then the cache-key will be a hash of the .hs and .hi files
<clever>
if the .hi dont change, the build gets reused
<clever>
ah, yeah, that could then become a bottleneck, would need to heavily optimize nix then
<elvishjerricco>
clever: Right, but merely invoking Nix like that takes time, and it's often going to be too much. Furthermore, that requires having a MASSIVE re-implementation of GHC behavior
nschoe has quit [Ping timeout: 252 seconds]
<elvishjerricco>
which is likely to be buggy and incomplete
<clever>
what part of ghc has to be re-implemented?
<clever>
just use a shake style build without `ghc --make` and it runs the wrapper script on every module
<clever>
though, now you need an external tool to run a build command on every module
<elvishjerricco>
You have to write a program that can determine exactly what all the modules are, what their outputs ought to be, and what their inputs are.
hamishmack has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<elvishjerricco>
These are all three complex processes in GHC
<clever>
"what their inputs are" is already solved in snack
<elvishjerricco>
I sincerely doubt that
<clever>
solved enough that it can build most of cardano-sl, but it fails due to a lack of -hide-all-packages
<elvishjerricco>
It may have "It imports these modules at a syntactic level" but that's not enough.
<clever>
what else is there?
<elvishjerricco>
TH, for one. C sources / headers. hs-boot stuff. Some others
<elvishjerricco>
Some others that aren't coming to mind right now
<clever>
TH works due to snack just getting the entire import list, recursively
<clever>
but TH actually fails, because it expects the .o files from TH to be in the -outputdir
<clever>
so i have to copy some of the inputs to the output, to make ghc happy
<elvishjerricco>
I ran into all these problems when I was trying to write a GHC wrapper that replaced --make with -M, to get better parallelism.
<clever>
ghc is a little upset that the .hi and .o from past modules, are in a different dir from the output
<elvishjerricco>
Turns out parsing the command line and determining inputs is insanely hard
<elvishjerricco>
clever: I don't see how that file is any better than -M
<elvishjerricco>
In terms of accuracy
<elvishjerricco>
Obviously that file is necessary for snack
nbardiuk has joined #nixos
<clever>
the biggest problem ive had with snack has been O(n^n) style problems
<clever>
it initially took over 3 days to eval a package
<elvishjerricco>
My approach to incremental Nix+Haskell is going to be to create a dirty variant of Nix, where you can mark some derivations as dirty, and whenever they get rebuilt they reuse the last builds working dir and output. It's impure and gross, but it seems like it'll be way the hell easier to implement.
<elvishjerricco>
Should be incremental across packages too
<clever>
ah
<clever>
that already happens by accident a lot, the result symlink winding up in src
<clever>
you just need to include the state in result, and then check for it in src
<elvishjerricco>
clever: Yea I thought about that too. Nix-the-state-monad :P
mayhewluke has quit [Ping timeout: 245 seconds]
pointfourone_ has joined #nixos
mayhewluke has joined #nixos
pointfourone has quit [Ping timeout: 252 seconds]
Itkovian has joined #nixos
<elvishjerricco>
clever: Though oddly enough, it seems like Nix doesn't actually treat a symlink in your working dir as a dependency when you add-to-store it.
<elvishjerricco>
So that's not GC safe
<clever>
ah yeah
silver has joined #nixos
run500 has joined #nixos
sigmundv has joined #nixos
pointfourone_ has left #nixos [#nixos]
<gchristensen>
I thought a result symlink would keep entire chains of of builds alive?
<clever>
but when you src = ./.; and it copies result back into the store, the src doesnt deoend on the path result points to, i think
pointfourone has joined #nixos
<elvishjerricco>
gchristensen: Doesn't look like it. `nix build nixpkgs.hello && nix path-info -r $(nix add-to-store $(pwd))` only prints the one path
pointfourone has left #nixos [#nixos]
<run500>
I want to provide the buildPackages version of an input package to nativeBuildInputs. How would I do this? Here's what I tried, and this didn't work: nativeBuildInputs = [ (myInputPackage.override { stdenv = buildPackages.stdenv; }) ]
<elvishjerricco>
I think something can only be a runtime input if its a build time input in the deriver. Obviously sources don't have derivers
<clever>
run500: if you only override stdenv, then every other input to that package are now in the wrong version
<run500>
any idea how i could do something like this? the package (protobuf in my case) is also a regular buildInput
<clever>
run500: have you tried just doing buildPackages.myInputPackage?
<elvishjerricco>
run500: There's a way to do it with callPackage automatically but I don't understand it at all
hamishmack has joined #nixos
<run500>
clever: there are multiple versions of protobuf attribute paths, so i wouldn't know whether to use buildPackages.protobuf (which goes to 3_6), or buildPackages.protobuf3_5, etc
<clever>
run500: just try one and see if it works
<run500>
clever: just tried it, and it selects a mismatched version. i need the versions to match with the one passed in as a buildInput
<clever>
you need a native for protoc and then a target for linking?
<run500>
yeah
<clever>
and what did you put into buildInputs?
<run500>
pkgs.protobuf3_5
<clever>
then you want buildPackages.protobuf3_5 in the nativeBuildInputs
<run500>
the idea is that ive been passed in any of the protobuf versions as a buildInput, protobuf3_1, or protobuf3_5, and i want to use the matching native version without hardcoding it
sigmundv has quit [Ping timeout: 272 seconds]
<clever>
ahh
<run500>
i could also pass in two parameters, one for hostPlatform and one for buildPlatform. but was trying to avoid that
<clever>
i think whats supposed to happen, is that you just accept protobuf as an input, and you put it into both lists
<clever>
and then the stdenv does some magic to make it cross or native, depending on which list its in?
Itkovian has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<run500>
clever: that makes sense, but tried it out and it doesnt seem to work, the hostPlatform version gets put on the PATH instead of the buildPlatform version
fendor has quit [Read error: Connection reset by peer]
<adamantium>
Hi, which pkg do you guys recommend I install to get most of the common network tools like dig and traceroute and things.
Thra11 has quit [Ping timeout: 276 seconds]
<jasongrossman>
aleph-: It's not the best time of day for the people who use home-manager. Can you check back in a few hours?
mutlu has quit [Ping timeout: 252 seconds]
<srhb>
adamantium: I'm not aware of any prebaked package that combines a lot of them
<srhb>
adamantium: So just get each that you need individually.
<aleph->
Heh what is the best? Morning EST?
<srhb>
aleph-: Did you already pose your questions? People that know about it may be around but reluctant to answer without knowing the scope of the question.
<jasongrossman>
aleph-: The people I'm thinking of are computerholics and are online most times of day, just not this time.
<jasongrossman>
aleph-: But yes, please ask your question.
<aleph->
srhb: Yeah fair point.
<aleph->
One sec, let me get my paste.
<aleph->
Does anybody see a reason why my i3.nix file would not be generating my i3 conf file in my home dir? https://paste.rs/I9f
<aleph->
Importing this into my home.nix and running a nixos-rebuild switch, but nothing happens it seems.
<Ralith>
adamantium: if you try to run the command, nix will tell you what package you need
<Ralith>
at least if you're using bash
<srhb>
aleph-: This is using home-manager as a module? Are you sure it's supposed to generate it in your homedir?
<srhb>
aleph-: I don't know the particular module, but usually they just wrap the application to go look in the store for the particular generated config
<dongcarl>
It is acceptable to add `bitcoind` to `master/nixos/modules/services`? Just wondering if there are rules for what services can go there and whatnot
<aleph->
srhb: Yep, supposed to in my home dir.
<aleph->
Rather the point of home-manager from what I've read.
camsbury has joined #nixos
camsbury has quit [Client Quit]
<srhb>
aleph-: Not necessarily. Let me look at the module...
<aleph->
Aye, thanks.
Ariakenom has quit [Quit: Leaving]
dvim has joined #nixos
<rembo10>
Are you running nixos-rebuild switch or home-manager switch?
<aleph->
I don't even care so much if it is generated in my home dir, I just care that it's being used by i3. Which it isn't.
<srhb>
aleph-: Right :)
zopsi has quit [Quit: Oops]
<srhb>
I do see xdg.configFile."i3/config" which does sound like a symlink to ~/.config/i3/config
<srhb>
aleph-: Interactions with non-nix-managed things can be tricky like that. Rule of thumb: If nothing changed for Nix, rebuild does nothing.
<aleph->
Aye
civodul has quit [Quit: ERC (IRC client for Emacs 26.1)]
<aleph->
srhb: So are there examples on using writeTextFile? To be honest, I'd rather just take my dot file and write it to .i3/config or .config/i3/config
<srhb>
aleph-: the general xdg module supports linking in place any file like that.
<srhb>
aleph-: (in ~/.config, for instance)
<srhb>
aleph-: writeText is easy: first argument is the filename, second is the contents (a string)
zopsi has quit [Remote host closed the connection]
drakonis1 has quit [Ping timeout: 260 seconds]
aleph- has quit [Quit: WeeChat 2.2]
zopsi has joined #nixos
aleph- has joined #nixos
<domenkozar>
tazjin: not really unless it's really important :)
<aleph->
srhb: So just do something like nixpkgs.writeTextFile 'FILE_PATH': ''TEXT'';
<srhb>
aleph-: No. First, that's writeText, not writeTextFile (which is more general and complex.) It will always be in the nix store. The first argument is merely the file name
<{^_^}>
[nixpkgs] @xeji pushed commit from @Lassulus to master « gitolite 3.6.7 -> 3.6.10 (#48562) »: https://git.io/fxgs2
<aleph->
Ah to hell with it, I'll just rewrite my config with the config option
__monty__ has quit [Quit: leaving]
<azazel>
is there anything in nix helping reading/writing YAML formatted files?
jperras has quit [Quit: WeeChat 2.2]
justanotheruser has joined #nixos
<srhb>
aleph-: What was wrong with that? Sounded right to me.
<srhb>
(Mind, I think you lose most of the advantages of the i3 module...)
<aleph->
srhb: https://paste.rs/fsZ causes this error "error: The unique option `home-manager.users.noah.xdg.configFile.i3/config.source' is defined multiple times, in `/nix/store/jh48xhxhm5qi2s2v2zi910cqjhhjfhsb-source/modules/services/window-managers/i3.nix' and `/etc/nixos/i3.nix'."
<elvishjerricco>
Cheery that's pretty close to what NixOS's initrd is, I think
<elvishjerricco>
Or most initrds, I think
mutlu has quit [Ping timeout: 252 seconds]
<Cheery>
well.. I'm installing this thing into virtualbox when the dl finishes
<makefu>
Cheery: there are also a couple of advances with regards to creating a minimal distro for routers (not-os by clever or nixwrt): https://nixos.wiki/wiki/Workgroup:Router
<makefu>
however these are more like another distro than NixOS
<fiatjaf>
azazel, nix-build will create new stuff at /nix/store every time I rebuild the project
<fiatjaf>
that will quickly take all my disk space
<Cheery>
Unix was built on the idea that there's a single vendor who keeps track of where everything is, and user software gets their place superimposed over the vendor's stuff.
<Cheery>
but today the systems have multiple vendors
<Cheery>
still, this original idea has stuck. The outcome is that I'm pretty much ubuntu user, not a linux user
<Cheery>
I feel that as sad. Because eventually the vendor of ubuntu does same abuse as the vendor of Windows.
<Cheery>
and I feel that I've wasted the effort I spent to use linux
<Cheery>
it boils down to the fact that everything should be placed somewhere, and there's not definite way to tell where that something is.
<Cheery>
but since there's no places for things, every software that's installed has to be told separately where something is
<Cheery>
which results in configuration being burden
<Cheery>
of course that's not user-friendly in any way, so people come up with their own ways to package software
<Cheery>
but most vendors do a miss hit there.
<Cheery>
the outcome is that Linux is getting worse.
<Cheery>
many small successes at a time
<Cheery>
and it boils down to some very fundamental things being left open.