<worldofpeace>
Jan Tojnar: would it have made more sense for guiPackages for flatpak to have been an enum. btw, since we removed epiphany from gnome its been glaring to me that we "don't really" have a default browser on deployed nixos https://github.com/NixOS/nixpkgs/issues/101729
julm has joined #nixos-gnome
julm has quit [Client Quit]
julm has joined #nixos-gnome
<jtojnar>
worldofpeace: not sure what do you mean by enum here
<worldofpeace>
type = types.enum [ "gnome-software" ....
<jtojnar>
oh, I think it makes sense as is, if we are to allow multiple DE’s installed
<worldofpeace>
right, like there could be a situation where u use plasma5 and gnome so you'd have two flatpak programs. but I don't really see that as really annoying because it's clear which those belong too since plasma5 appears to bring it in and vice versa
<worldofpeace>
hmm, though maybe we should do a flatpak.noGui option. still not sure
<jtojnar>
worldofpeace: I am starting to doubt the option
<jtojnar>
thinking about it more, I would prefer adding `mkIf services.flatpak.enable` in each DE
<worldofpeace>
do u mean an mkMerge or like ++ mkif services.flatpak to systemPackages?
<jtojnar>
right, I do not see much of a point in the indirection
<jtojnar>
with the reasoning I came up on the issue
<jtojnar>
“The reason we did that for the stores was not to install relevant software, but to not install useless software, which would be installed by default on other distros with working PackageKit integration.”
<worldofpeace>
Jan Tojnar: I feel like, since the indirection is internal, it just makes it so we don't have to write a conditional over and over
<worldofpeace>
Yeah, I'm not super sold on "default browser" like where u said it's a preferential choice. But at the same time I feel like nixos needs to "bless" or "make official" a whole lot more
<jtojnar>
worldofpeace: another criterion we could use is how many people would use the default value compared to how many would change it and how much effort would it be for them
<worldofpeace>
Jan Tojnar: So since there's the option enableDefaultBrowser all they'd have to do is disable it forever and be sure to read the release note
<worldofpeace>
I think the marketing team has a limesurvey instance
<jtojnar>
that would feel a bit unfair, when I would just get do nothing and get my preferred Firefox
<worldofpeace>
yeah +1
<jtojnar>
we are basically trading minor convenience for one group for minor inconvenience of another group
<jtojnar>
so to get good answer it would be nice to see how big are the groups and the (in)convenience
<jtojnar>
I would not expect it to be worth it for browsers but probably fine for power management but have nothing to back it up with
<jtojnar>
my perception might be coloured by the factor that I consider the minor browsers (unfortunately) not very useful for modern web, and thus for general user
<worldofpeace>
yeah, the useful takeaway here is possibly having optimized roles that we can be aware of. As you said, since the tradeoff is minor inconvenience for minor convenience we'd probably see people equally disagree/agree on both sides depending on that outcome for them 😸
<jtojnar>
worldofpeace: another argument against the flatpakGui option is that gnome-software actually ships dbus services
<jtojnar>
so it should technically go to dbus.packages as well
<jtojnar>
though for some reason D-Bus services are still picked up from environment.systemPackages
<worldofpeace>
though with like powermanagment, calls like turning on tlp desktops would have more feasible benefits and so forth with the other examples you've made. I actually have had a thing in my local configuration that does `hardware = { cpu.intel = true; audio = true; battery = true;` etc.
<worldofpeace>
Jan Tojnar: I think the dbus module actually does this intentionally
<jtojnar>
right, I have no idea about what power management settings I should use so I would appreciate a “rich desktop” profile being imported by GNOME
<jtojnar>
it is weird we do that for dbus but not systemd
<jtojnar>
again the convenience × explicitness divide, where I still cannot decide on a side
<worldofpeace>
<jtojnar "it is weird we do that for dbus "> I'm not really sure what the benefit is of not. Like, if we did it for systemd we could remove probably a few "just for this program" modules. Like the evince module could be deleted because systemd.packages would have system path
<worldofpeace>
<jtojnar "again the convenience × explicit"> I think maybe we don't really need to side? We can just stay flexible to provide both... like I did mention there could be a distro that sides to make everything as convenient as possible, but I feel like there's no reason these two can't complement eachother. If u want to be explicit turn something off and do what you want, and what's convenient you never care or notice
<worldofpeace>
lol, do you even call that general purpose
<jtojnar>
I cannot really come up with an argument that would satisfy me with a pragmatic hat on
<jtojnar>
I guess I just feel general unease about moving control out of Nix, into imperative system generators
<jtojnar>
exacerbated by my typical disgust of global state
<jtojnar>
while still using basically a standard Linux distro generated by Nix
<jtojnar>
maybe people using some kind of more esoteric setup would have a better answer
<worldofpeace>
I mean, would it be useful to ever install a program that has polkit definition and a systemd definition without having either of those services know about them? Perhaps... maybe if the package can upfront say "needs polkit, needs systemd, needs this portal dbus etc."
<worldofpeace>
oh wait i think there's a thread where u go into detail about that a bit
<jtojnar>
maybe it is just some kind of guilt that by making on-demand modules on-by-default we are taking NixOS out of the hands of the hardcore users, to whom NixOS belongs just as much as it belongs to us
<jtojnar>
that does not even make sense
<worldofpeace>
<jtojnar "that does not even make sense"> what I said or what u said?
<worldofpeace>
(it's late rn for me I will admit)
<jtojnar>
what I said
<jtojnar>
<worldofpeace "oh wait i think there's a thread"> yeah, I think I remember. At that point, I was probably leaning into “explicit everything” mode, fearing that it would lead to globally installing dependencies as well
<worldofpeace>
lol, it kinda did to me. like on-demand modules on-by-default, from a usability standpoint and marketability is more accessible. the best observation about nixos I've seen is the defunct users are the developers and I think that is changing. I think it's just how to change so that both can work together? It's also true that, other distros are made so different focuses can be created. like nixos as general purpose
<worldofpeace>
and maybe another nixos distro for ultimate convenience etc. I've just yet to see that done in a way that isn't fragmenting in linux
<jtojnar>
yeah, it's late for me too
<jtojnar>
I am still looking for solution without compromises but not sure if one exists
<jtojnar>
so what we have is kind of the best we can get
<jtojnar>
* so what we have with NixOS module system is kind of the best we can get