<sir123>No, but I'm not particularly fast, sorry. Three parts: a link encap:ethernet, a link encap:local loopback and a wlp3s0 link encap:ethernet. I'm using a wireless card that I know works under free software
<mark_weaver>I'm pretty sure that we could configure user-specified aliases for those devices.
<mark_weaver>udev configuration files provide a lot of flexibility
<jpt4>civodul: User attributes may be mutable, but they are also portable. If a particular mutation is deemed canonical, e.g. by specification in a system wide config file, transplanting the config to a different machine should reproduce exactly the state at the time of specification.
<civodul>jpt4: that's what happens: 'usermod' is run to ensure that the configured account attributes are effective
<civodul>what does not happen is removal of no-longer specified accounts
<davexunit>I worry about cruft accruing on machines, as seen with puppet and co.
<jpt4>Concerning unspecified accounts, where is root? Is there a %base-users?
<davexunit>if I as the sysadmin must take care to remove the users manually, I hit scaling problems when I try to revoke a user's access from 100 servers.
<davexunit>ideally, I'd like that to be a new generation of my GuixSD system.
<davexunit>guix can't help with deleting home dirs in any sane way, but it could ensure that the user is no longer valid.
<mark_weaver>jpt4: there's no %base-users. There's %root-account defined in gnu/system.scm and automatically added to the list of accounts provided by the user in 'operating-system-accounts', defined in the same file.
<mark_weaver>davexunit: for the ideal mostly-immutable system, but where you want a few things mutable like databases, it might be best to recreate your root partition from scratch everytime with 'guix system init', and then keep your explicitly mutable data on another partition.
<mark_weaver>the mutable data could be put into the system with either symlinks or bind mounts to the mutable partition.
<davexunit>to me, there's a distinction with something like a database. the creation of a database wouldn't be something you specified in your OS config.
<davexunit>that's the kind of stateful stuff that guix need not bother with.
<jpt4>Unless legacy unix is to be abandoned entirely in favor of GuixOS (as opposed to GS*Distribution*), the aesthetic is one of guix as a safe, immutable overlay manipulating or replicating the function of imperative primitives.
<jpt4>Thus, the more functionality that is co-opted into the immutable sphere of control the better, as it disincentives system adminstration outside of it.
<mark_weaver>I think different users will want different sets of things managed immutably. for example, most casual users probably want their network manager to remember wireless networks they've connected to.
<jpt4>mark_weaver: Why is a record of observed networks not immutable? As a time series, its monotonic. Also, is not "overwritten completely" a slight exaggeration given that previous configs can be resumed?
<mark_weaver>davexunit: mmm, it probably should be, but wicd doesn't work that way.
<mark_weaver>(we should deprecate wicd btw, since it's no longer maintained)
<jgrant>mark_weaver: Oh it isn't? It'd probably be realtively trivial to roll a interface for Wpa_supplicant and iw, really.
<mark_weaver>jpt4: well, some people might want to declare the list of wireless networks to auto-connect to (and their authentication info) in the OS config, such that they could remove an item from that list and the next 'guix system reconfigure' would completely overwrite the wireless config, removing anything that had been added by convenient GUI wireless config tools.
<davexunit>my rule of thumb seems to be: if it can be specificed in an OS config, it ought to be stateless. everything outside of that is stateful and guix will respect that.
<mark_weaver>jpt4: but many users want to be able to use a network manager GUI to join a network without having to reconfigure their system.
<jpt4>mark_weaver: I see, though I wonder if guix has the concept of "live reconfiguration"? If kexec can swap kernels out from under the user, why would a guix-integrated wifi-menu not be modelled as the input to a new, transparent system reconfig?
<mark_weaver>two people can be logged in to the console as well. sometimes two people share a computer, and some desktop environments support quick switching between them.
<mark_weaver>(where there are actually two X server running simultanously)
<mark_weaver>jpt4: the operating system object aims to be a pure function of the configuration file and the version of guix (e.g. git commit)
<jpt4>mark_weaver: Indeed, absent a revision controlled tree of (config, OS) pairs, I rescind my previous remarks concerning the immutable potential of network connections.
<mark_weaver>it's affected by any local changes you've made to your guix source tree, if you run guix out of the source tree (as I do)
<davexunit>jpt4: I highly recommend keeping your configs in version control, but the state of your text files is not the concern of guix ;)
<davexunit>I have 2 extra repos, one for configs, and one for extra packages. could probably roll it into one.
<jpt4>davexunit: Urbit and guix/gsd are my two favorite systems programming projects, the first of which influenced my former comments. However, I recognize the difference in scope and application between the two, and thank you and mark_weaver for clarifying.
<mark_weaver>jpt4: glad to have you here, your comments have been quite welcome