<civodul>GNUtoo: if you're building an image, it may be okay to have secrets of that image go through the the store of the machine that builds the image, depending on the use case <GNUtoo>(and ideally handle things like resizing the image too as there is some good reasons not to do that as it is done now to save space in the store) <GNUtoo>That'd also end in the store of the target image in some cases, right? <civodul>another possibility: for the childhurd (a GNU/Hurd VM), there's a "secret service" whereby secrets are passed from the host to the guest at boot time <civodul>such that the guest never has those secrets in its store <GNUtoo>My use case is deploying a VM with a VPN inside and various services (mail, potentially shells, etc) <GNUtoo>The VPN is only to easily get a public static IPv4 address and IPv6 range <civodul>if that VM is hosted by Guix System, the secret service thing could work <GNUtoo>So for now I've managed to write a python program that mounts the roofs all without root, so I could easily copy files inside <GNUtoo>(though very few cases are covered) <GNUtoo>So that will work for me but I think having some abstraction here could be beneficial for Guix in general <GNUtoo>for instance currently with system image, having big --image-size take a lot of space in the store <GNUtoo>Being able to transform the image to grow, add files and so on would be a good idea I think <GNUtoo>(Though one may also want to have big images in the store to not have to spend time to grow them) <GNUtoo>I'm thinking of something like that: $ guix system image -t qcow2 --grow-image=10G --add-from-tarball=./secrets.tar.xz --add-from-tarball=website.tar.xz -o vm.img <GNUtoo>Though I've no idea if it's easy or hard to add <civodul>note that you can always do --image-size=10G; the qcow2 image won't take more space until you actually use it <GNUtoo>Though that doesn't work for all image formats <civodul>as for secrets, something like you describe should be possible <GNUtoo>The issue with --grow-image=100G would be also that people typically use /tmp for the guix tmp and it's typically on RAM <maximed>Then why not use "--grow-image=100G -o some-directory-not-in-/tmp/vm.img"? <GNUtoo>That could work if it's done in place, indeed <maximed>Even better would be "--output-partition=/dev/???" <maximed>Maybe "guix system init /mnt" works like that (not sure) <maximed>or maybe that messes up /etc/passwd and the like, I dunno <GNUtoo>In any case if it's easy enough and that I manage to do it I'll probably only work on add-from-tarball and I had --grow-image in mind mostly to show a more general picture of what could be done if we have an abstraction like that <GNUtoo>We could probably handle things like cryptsetup, lvm and so on there too <GNUtoo>Though it'd probably need some key and/or passphrase handling to be done in a safe way <GNUtoo>--password=mypassword is not that safe when most users can do ps | grep password <the_tubular>root 22126 0.0 0.0 0 0 ? Z 12:00 0:00 [mcron] <defunct> ***califax- is now known as califax
<dragestil>I just installed guix system on a server. Does the installation generate a file of the current configuration, i.e. guix deploy this file would produce the same result? If so where can I find this file? <dragestil>why does guix download a lot of stuff when I run guix system reconfigure on the current config (i.e. no change)? <iskarian>dragestil, if you've done a guix pull since the last reconfigure that might do it <dragestil>Another question is, if I change the openssh config, say adding (x11-forwarding? #t) (permit-root-login 'without-password) to the current config, and do system reconfigure, I have to wait for a long time, compared to editing sshd_config and restart sshd on say debian <iskarian>how long is a long time? I think reconfigure doesn't restart services sometimes, so a `sudo shepherd restart sshd` might do it <iskarian>Yeah, looks like you'll have to either manually restart it or tell it to reload the config (if the x11 shepherd service supports that) <dragestil>do you mean I don't need to do system reconfigure for the change to take effect? <iskarian>No, you'll still have to do that to update the underlying configuration <iskarian>Oh, maybe the ssh daemon isn't restarting automatically if you have any open ssh sessions? <dragestil>I feel like it is doing a lot of things unrelated to the two lines <dragestil>iskarian: I don't know, shouldn't I wait until system reconfigure to finish before restart sshd? <dragestil>if it is debian on the same machine, it takes <10 seconds to achieve the same goal <dragestil>are there examples of the guix system used in production servers <PurpleSym>rekado: Okay, I’m fine with keeping /bin/sh as-is. <efraim>thought I was almost done with julia, turns out I need to build it a few more times and the newer pcre2 is actually needed :/ <atka>proper way to blacklist nouveau? under (operating-system, modprobe.blacklisth=nouveau? I'm trying to force using integrated graphics. <atka>efraim: thanks, I'll give it a shot. <efraim>where are emacs packages supposed to be installed? either global or translate-shell are wrong. %output/share/emacs/site-lisp/package-version or no package-version? ***Kimapr5 is now known as Kimapr
<ekaitz>civodul: I just sent a "solution" to a weird segmentation fault issue on the checks of mescc-tools: updating seems to solve the issue somehow <efraim>leoprikler: thanks. I'll move global. <efraim>Also I think I almost have global + ctags working with guile programs, I just want to make it more automated <civodul>is it the same kind of issue that you were seeing? <ekaitz>civodul: yeah basically! i didn't saw that. We can close #48595 then! <civodul>it'd be useful to see all the channel commits <civodul>mothacehe: also, a colleague of mine tells me that Thunderbird and the W3C validator reject the RSS feeds *civodul .oO perhaps i should make proper bug reports instead of bugging people :-) <ytc>hello. how much time does your boot time take on guix approximately? and please state that if you're using ssd or hdd. <ekaitz>ytc: ssd -> 1 min? probably less <ytc>i think shepherd is a little bit slow. <civodul>yeah, it's not as efficient as systemd <ekaitz>well my computer is much slower using the ubuntu install it has in the nvme :) <bricewge>Is there a way to modify essential-services? <bricewge>But I want to support additional UNIX group membership, to be able to modify an accounts from a service <ekaitz>oh I'm not sure what to answer :) <ekaitz>bricewge: I basically tried to help but I can't <cybersyn>sneek tell ytc later: my lightweight sway desktop reaches login in about 20 seconds <sneek>ytc, cybersyn says: later: my lightweight sway desktop reaches login in about 20 seconds <ekaitz>I mean I know how to change the list but not how to change their config, which is what you are trying, right? <bricewge>Inheriting from an OS, I want to modify an UNIX account from the new OS <bricewge>For example "alice" is defined in base-os with default group membership. But in child-os (inheriting from base-os) I want "alice" to be a member of group "admin". <bricewge>At the end I would like to be able to do that from a service. <civodul>bricewge: hi! services can only "extend" other services, such as account-service-type; they cannot "modify" the final value of other services <civodul>(a big difference compared to NixOS) <civodul>so you cannot write a service that fiddles with user accounts other than those its creates <civodul>however, you could write a procedure that takes an OS and returns an OS, making the transformation you describe aboev <bricewge>civodul: I thought about doing that but it seems more versatil doing it from a service. <bricewge>I understood that mos OS fields were meat to be modifiable from services. But it looks like I was wrong. <bricewge>So there isn't a preferred way to modify an OS, and it depends on which field we want to change? I find it confusing <mbakke>there is a regression in haskell-build-system since 7d873f194ca69d6096d28d7a224ab78e83e34fe1: packages that use #:cabal-revision (such as 'ghc-old-locale') are failing <mbakke>comparing the builder with 'master', it seems the problem is that #:cabal-revision ends up as ("revision"), whereas the builder expects it to be a plain string <mbakke>however if I mangle the procedure to remove the list, I get "invalid G-expression input" <mbakke>(for an otherwise good-looking <origin>) <civodul>mbakke: what's this "cabal-revision" input? <mbakke>civodul: if you have built 'ghc' on core-updates, you can simply try to build ghc-old-locale <civodul>looks like i'll have to build a whole bunch of things :-/ <civodul>what error do you get with current core-updates? <civodul>thing is, that origin gets wrapped in a <gexp-input> somewhere <civodul>gexp inputs are not "lowerable", but you're allowed to have them in lists in ungexp-splicing <civodul>so the trick here is to use #$@ (ungexp-splicing) <civodul>hope that makes a little bit of sense <civodul>it should fix the problem anyway :-) <mbakke>it works!!! that is some dark magic :-) <civodul>yeah, let's keep it for ourselves :-) <mbakke>civodul: will you commit it? :-) <ekaitz>civodul: how are the guix iso images generated? I suppose they use guix system image to be generated but is the description of the images anywhere in the guix repository? (I'm still having issues to find stuff in the code, after all this time *sigh*...) <ekaitz>mbakke: thanks! it's a small section, i didn't see that! thanks!! <mbakke>civodul: excellent, and thanks for the quick expedition! ungexp-splicing would have never occured to me. <civodul>mbakke, mothacehe: what about getting ci.guix to build all the packages? <civodul>maybe we need to fork "core-updates-frozen" first <civodul>or, in the meantime, we could have it build etc/release-manifests.scm <mbakke>civodul: I think the branch is good to go.... however glibc will release 2.34 this weekend, I'm conflicted as to whether to wait for it. <mbakke>indeed, release-manifest.scm would help many people get started on that branch without private build farms <efraim>i'd not take it, we'll be running aroudn fixing all the glibc version incompatabilies that pop up <civodul>mbakke: i agree with efraim, i'd lean towards staying on 2.33 <mbakke>sounds good! then I think we can freeze (I have a binutils bugfix that needs to be pushed) <mothacehe>just create the frozen branch + cuirass specification <mbakke>oh, there is already a "core-updates-frozen" branch: should I push it there too? <mothacehe>mbakke: yes, the plan is to stabilize the frozen branch while keeping the core-updates branch open *mbakke starts local world rebuild <mbakke>with all the changes in that branch, perhaps this will become Guix 2.0? :-) <civodul>mbakke: i did consider that actually... <civodul>but i'd like to get another big change in to fully justify in <civodul>but so far life has been getting in the way <mbakke>civodul: makes sense :-) we also have a long way to go to get rid of input labels everywhere and introducing more gexp'd arguments. <civodul>mbakke: we don't *have* to introduce gexp'd arguments everywhere <civodul>for input labels, we'll have one big commit removing most of them <mbakke>yes, me neither; they won't be missed! search-input-file & co are much nicer. :-) <rekado>before 2.0 I think it would be good to collect 100 papercuts and include fixes for most of them. <rekado>there are some quirks that we all seem to have accepted, but fixing them for good really doesn’t take a lot of effort <roptat>I think grafts are what's making my life a bit difficult at the moment <rekado>I’d also like to declare my love for phasing out input labels. I always found them to be somewhat clunky. Good to see them go! <roptat>it's always a bit difficult to predict what will happen, it makes guix download more than necessary just to check that it does have the graft it needs, ... <roptat>I don't say we should get rid of grafts, but we should improve the UX around them <rekado>I wonder if much of the confusion would disappear if we could ignore grafts until the very end. <roptat>oh, that's exactly the symptoms I got when trying to get an environment for an ocaml package that had a lot of dependencies (15 direct, but 119 with propagated inputs) <rekado>i.e. first build everything without grafts; then start a new phase, announcing graft computation, which then does the same as it does now <rekado>(hmm, aren’t we doing this already…?) <rekado>roptat: I’d be happy if you could comment on that issue with whatever data you have collected. <roptat>I think we're doing something similar yes <roptat>mh, the issue is that this particular package is not free software, although its dependencies are, but they are not part of guix yet <rekado>if you can reproduce it with a subset of the dependencies (even if you have to build a dummy package that has the same set of inputs) that might be helpful. <roptat>"GC Warning: Repeated allocation of very large block (appr. size 67112960)" <roptat>also, the profile building step is very long <roptat>what should I take into account for memory consumption, virt, res, shr? <roptat>and apart from looking at top for as long as the command runs, is there a way to record memory consumption of a process? <efraim>On the riscv64 side I'm up to guile-final <rekado>roptat: yes, you can use “time -v” (the application, not the built-in); it shows max resident memory <roptat>I'll let the profile build, and record the memory for just computing it afterwards <roptat>right know, the builder is taking 1.5g resident <roptat>so for instance, one issue I have with grafts is related to texlive. I always build it with --no-grafts, because otherwise the gc will collect the ungrafted version, and next time I need it, it will build the ungrafted version again to find out it already has the grafted version <roptat>would it help to have reference information in the narinfo? <roptat>or would that break the security model? <marusich>I don't think the security of substitutes or grafts depends on any secrets (beyond the signing key) being hidden. <marusich>I'm not an expert on grafts though, so a second opinion might be good. <roptat>I mean, if the server fails to advertise a reference, my local guix will think it doesn't have to graft, and I'll be left with an ungrafted version <roptat>but at the same time, my local guix also trusts the server to provide it with a genuine copy of the binary package, so... <wirez>can i install any version of any pkg, or only the latest version? <marusich>However, in practice the path of least resistance is to use the versions of packages that are included in whatever version of Guix you're currently using. <wirez>something liek a semver software dep would be best, like you say a package but then also a version, and the version pattern controls the version you get, and even in 2 years the version your pattern says will be installed <wirez>like python3 to get latest of 3.x, python38 to get latest of 3.8.x, etc <marusich>If you want something like that, then right now the best solution is either "guix time-machine" or a "guix pull --commit=HASH" (replace HASH of course with the actual commit hash) followed by a "guix package -i PACKAGE" <marusich>Sometimes, Guix maintains multiple versions of a package for a while in the regular package collection. For example, there are few versions of gcc available to use. <marusich>There is no feature that specifically will interpret a package version in a spec like python@3.8.1, find a package in prior version of Guix matching that spec, and then build it. <wirez>that means builds aren't reproducible no? <marusich>If you have the version of Guix that you previously used, and if all the builds are reproducible, the entire collection of software is reproducible. <roptat>it's reproducible if you record the version of guix you used (which is the case by default, there's a provenance file that records that info) <wirez>but you can have a guix config, install it, end up with versions of the software that in a year you reinstall same config but get different versions of the software <wirez>the pkgs you declare wanting installed <marusich>That will not happen if you use "guix time-machine" or if you run "guix pull" to ensure you're using the same version of Guix as before. <marusich>The name "Python 3.8.1", even with a version number, does not exactly specify the software being used. <wirez>sure but it's more, it's useful <marusich>What about its dependencies? What about if I customize the code for "Python 3.8.1" and keep the same version number? These changes are reflected in the commit hash (i.e., version) of Guix and its package collection. <wirez>ya well that's all the more reason to want as much control as we can get <wirez>if i can lock something to y.x, i greatly narrow the scope of my problem if a .z is different <marusich>I agree with you, but I don't see why you can't do that. <marusich>For example, what stops you from declaring the software you are using, including the version, in a manifest, and then including the Guix channels in use in a channels file, and then later on running "guix pull --channels=FILE" followed by "guix package -m MANIFEST" to install exactly the same stuff as before? <vagrantc>upgrading guix is basically saying "update all the software to newest versions and rebuild it with the newest versions" ... the way you get reproducibility is you upgrade to the exact same set of package versions. <marusich>Guix is designed to be a rolling distribution, so if you run "guix pull" you are going to get different software for "python". If "Python 3.8.1" is still included in the distribution after you run "guix pull" (often it is, since it is popular and likely to remain for a while), it is likely that its dependency graph has changed, so it could behave differently, despite the version number being the same. <wirez>vagrantc so you can set which versions of all programs you want to install? <marusich>What I'm trying to say is that you CAN exactly specify the software used, and you CAN install it two years from now (assuming sources are available), by using "guix time machine" or "guix pull". <vagrantc>wirez: for a given generation of guix, you'll get a sepcific set of versions of software <wirez>the most important thing is i need to be able to totally specify a known good config, and get it byte for byte over time <marusich>But the way in which you accomplish that is different than simply saying "Python 3.8.1", since that statement is not enough on its own to exactly describe the closure of software used for an exact version of Python. <marusich>In practice, getting it byte for byte is difficult, since not all builds are actually reproducible in practice. <vagrantc>wirez: bit-for-bit reproducibility is maybe only 80%, depending on exactly which packages you use <marusich>Guix makes it easier to achieve reproducible builds, though. <wirez>if there's a way i can run program --version and see the exact x.y.z i set, good <dstolfa>you can't do byte for byte for certain software, especially if you enable stuff like PGO <dstolfa>guix tries its best to achieve it though <dstolfa>but sometimes the build gets the current date <marusich>wirez, the biggest risk to the ability to rebuild software in the future with Guix is that the sources might become unavailable, or they might change. For example, if ten years from now you try to build "glibc-2.33", but the source for that has changed or disappeared from the URL recorded in the package definition, Guix will fail to build it. <marusich>there are some steps it takes to avoid that, though, such as looking up the source by a content-addressed name in other places, like the software heritage project. <wirez>marusich that's not as important to me as the mechanism for multiple versions being supported <dstolfa>well, guix supports multiple versions <wirez>i've had it with OSs that will let me upgrade pkgs, but don't provide even the last 2 versions or so <wirez>so i upgrade a package, it has a bug i didn't expect, and now i can't work <wirez>man that's gonna be a relief <marusich>OK. The path for you to reproduce what you have is this: describe the software you use in a manifest (so you can install it with guix package -m manifest.scm and similar), and make sure you record the exact version of guix and any channels you used to build it (e.g. the output of "guix describe --format=channels", which is suitable for input to "guix pull --channels=FILE"). See... <marusich>But yeah, 100% bit-for-bit reproducibility is very hard to do when building from source. <dstolfa>also, note that you can `guix package --export-manifest` to get your current manifest <wirez>i don't need 100% it's just a goal. better than what i have now is good enough <marusich>In practice, the only way today to achieve 100% bit-for-bit reproducibility is either through very difficult, tedious debugging and fixing, to make the software build reproducibly. Or, to store an archive of the built result so you can re-use it as-is, without rebuilding it. <wirez>any place to see the guix system growth? like userbase, installs <marusich>Yeah, that's the case for a lot of use cases. <marusich>Hmmm, well, I try to use Guix whenever I can, but it's hard. The ecosystem of free software still often expects a traditional distro environment, to say nothing of the non-free world, so there are always a lot of "gotchas" when using Guix. <marusich>I think, if you have full control over your own infrastructure and environment, you would be in the best position to adopt Guix for most purposes. <vagrantc>honestly, guix *should* be able to get more like 95% reproducible with some effort ... as debian does it and intentionally varies more things <dstolfa>guix works really well in datacenters and on foreign distros on timesharing systems (e.g. if you have RHEL 8 and a bunch of users on it that want their own packages) <dstolfa>guix system i find works reasonably well as a desktop/laptop, but some things require docker to work <the_tubular>There's no telemetry in guix, this would be hard to guess <dstolfa>e.g. if software really doesn't want to work on guix and you don't have time to write a service for it, just use docker <wirez>marusich what kinda gotchas in guix? <dstolfa>you can get away with a lot of stuff like that <wirez>the_tubular maybe downloads? <marusich>wirez, for example, suppose you want to try out Rust. What do you do? You go to their website, and it says "use this script to install rustup" <marusich>If you do that, your story will end in tears. <marusich>The script doesn't know about Guix, and rustup doesn't behave correctly on a system like Guix. <dstolfa>marusich: doing that on any distro ends in tears <the_tubular>I'd check maybe the contributors wirez, that might be a good metric <dstolfa>in fact, everything about rust's ecosystem ends in tears <marusich>dstolfa, that's fair; it's a particularly bad example. <wirez>marusich oh true. ya rustup sucks <vagrantc>also, if you're interested in reproducibility, there's currently a meeting on irc.oftc.net #reproducible-builds :) *dstolfa really wishes rust stopped being so crap at distributing their language so he can use it for certain things <the_tubular>Also, making a ISO with guix is pretty easy, that means people probably aren't hitting the servers downloading the ISO multiple time, they probably just share it between each others <marusich>But OK, for example, consider something like PyCharm community edition. If you just download it and try it out on Guix System, the installer might complain it doesn't know how to install on this distro type. Even if you get it to work, you might find out that some of the pre-built executables don't work because they were built to expect libraries to be present in specific locations on the system, which is not true on Guix System. Again, this is <marusich>something that can happen with any GNU/Linux distro, but it's more frequent with Guix System because Guix System specifically avoids the Linux Filesystem Hierarchy Standard in order to avoid accidentally causing installed software to unintentionally use the wrong version of a library. <marusich>Stuff like that is not insurmountable, but in practice after years of using Guix System myself, I can say it sometimes feels like a death by a thousand cuts. <marusich>It's like, come on, again? I just want to try this nifty thing. So, sometimes, using Guix on top of a traditional GNU/Linux system may be the path of least resistance, depending on your situation. <marusich>But yes, none of this is Guix specific. You'd have the same troubles if you tried using Nix, for example. <the_tubular>I'll be experiencing this soon, marusich, will have to execute a binary on my system. <dstolfa>a lot of the time you can work around this issue by setting LD_LIBRARY_PATH, LD_PRELOAD and at worst, patchelf <dstolfa>e.g. i had to get mattermost running and my god... <marusich>Right, that's true. It's just that learning that you have to do that, then learning how to do it, is painful. <wirez>the_tubular ya good point, if you have a known good config no reason to not just bake an iso and use that file <marusich>For what it's worth, I think Guix provides tons of benefits that you simply can't have on other distros. So I like it a lot. <wirez>dstolfa damn i wanna run mattermost, that bad? <dstolfa>wirez: you can do it through flatpak, it's the path of least resistance <dstolfa>i wanted to get mattermost running without it as an appimage, and that was painful <wirez>does guix have an escape hatch so you can take software that isn't upgraded for guix and still run it but from like an isolated container like hiv in quarantine <dstolfa>you can use docker just fine. same with lxc/chroots <marusich>Not at this time. If you need that, the best solution is to use Guix on a foreign distro. <marusich>So you can use Guix System, plus docker, and use Docker to run any old docker images. <wirez>ah ya, virtualization means we can run another OS true <marusich>Yes, that's another option which does work. <wirez>would be cool to see guix download stats from your official infra <marusich>Nix has some kind of command that lets you temporarily set up a FHS environment, like "guix environment" but it sets up the FHS environment like a normal distro would be. Guix doesn't have that (the closest thing would be to run Guix on a foreign distro, or use Docker, or use a VM). <marusich>I don't know though. Every time somebody "solves" a build problem by saying, "here, just use my copy of libcrypto.a and you'll be able to build this fine", I thank my stars for Guix. <marusich>(True story, by the way. I have seen that happen.) <dstolfa>marusich: on most systems i often need to bootstrap a bunch of dependencies manually because the ones in the existing system don't work for what i'm trying to do <dstolfa>if i have enough resources and need to do this for enough machines, i can make my own package repository with these things, but more often than not, that's not the case (: <wirez>tbh i dunno how anyone used computers before stuff like guix. imagine manually typing out commands to configure a server, or running some stupid config mgmt thing, and never knowing if your system state is out of sync with your desired config? like wtf <wirez>dstolfa is this a prob with guix or linux or? can ppl use guix to get real work done? <dstolfa>wirez: this is a problem with every system in existence <dstolfa>"i need to test a particular piece of software using my libfoo, but my libfoo also depends on libbar and libbaz which it didn't before because new functionality is hard sometimes, but the software itself depends on libbarv0.1, not v0.2 so here we are" <marusich>I'm still often surprised by how much manual dependency management is tolerated, expected, or even encouraged, by everyone who builds software... <dstolfa>also regarding managing a fleet of servers that don't use guix... i use ansible and version the system myself with a sentinel file <marusich>Usually, even people who like systems like pip or cargo seem unconcerned about the fact that they do nothing to manage the dependencies for other languages, in particular the underlying c toolchain <dstolfa>it does, but what else can you use on non-guix systems <dstolfa>spoiler: they all suck, ansible just sucks less because you don't need to bootstrap a daemon <wirez>maybe remake it in go or smth <marusich>There is something to be said for mutability (it's fast, the iteration time is good for experimentation), but I think that in the same way that mutable data structures can theoretically be replaced by persistent data structures, so too can mutable distros be replaced by "persistent" distros like guix. <dstolfa>that doesn't even matter honestly, the problem is the way it's configured in yaml and the fact that they didn't have nested loops for the longest time because their loop item was always called "item" <dstolfa>which also means you can't call things "item" <marusich>dstolfa, that is the general consensus I see around me: all the build systems and dependency management systems suck, to more or lesser degrees. I am coming to believe it. <wirez>i think mutability should be opt in instead of opt out like most OSs <marusich>It is also important to remember the idea of "worse is better"; sometimes, Guix may not be the right tool for the job (yet?), and that's OK. <dstolfa>i've worked across many systems and i can safely say i hate all of them to some degree :P <marusich>however, Guix is IMO the least worst option <wirez>dstolfa any OS you think is better than guix? <wirez>for getting work done. servers, workstation etc <marusich>wirez, "better" is kind of subjective. it depends on what you are doing. <marusich>Like, think about compliance for a company <wirez>where's it excel where's it not great? <marusich>Even though Guix provides great bootstrapping guarantees, that isn't very useful for most companies. <marusich>I mean that's what we're saying, good tech is tech that lets you get your job done <dstolfa>wirez: guix is a good target for multiuser environments on time-sharing boxes or as a way to provision test boxes <dstolfa>it's not a very good target as a base for a time sharing system <dstolfa>you can't kpatch like you can on RHEL <dstolfa>on workstations, you can use whatever you want really <dstolfa>i've used anything from RHEL to guix to freebsd and openindiana <dstolfa>so what i do in that scenario is have something like RHEL and then have guix set up on it for others to use in their user profiles <wirez>so i guess only use guix for webserver if you have multiple so you can reboot them rolling? <the_tubular>There are solutions so a kernel change doesn't make you reboot <marusich>I wish you luck on your Guix journey, wirez! Guix is a fantastic system. It has the best design of the current OSes that I've seen, and I hope that its pain points are just temporary on the path to world domination. :) <dstolfa>the_tubular: yeah, but they aren't as integrated in guix in my experience. in RHEL you can just dnf install the necessary kpatch stuff and dnf will handle it <the_tubular>Never used it though, I can take a 3 minute downtime <wirez>marusich tyvm i too have high hopes <marusich>wirez, just keep in mind that right now, sometimes another tool may be better depending on the case. If Guix is a hammer, not all problems are nails. <dstolfa>if they were as integrated as they are in RHEL, you could just run an LTS kernel and rely on kpatch for security issues, upgrade once every 6 months and that's it <marusich>like, the only downside i have with guix, really, is that sometimes the effort required to get things working with it is just so much higher than "simply using another distro" - in times like that, using the other distro right now is a good choice. But it's also an opportunity to get hacking on an improvement to Guix. <dstolfa>yup. currently i use guix where it makes sense, i don't try to force things it obviously doesn't do yet, but i do have some "alpha" stuff running in production :) <wirez>imo you should dogfood and use guix for everything <dstolfa>wirez: sometimes it's just not possible unfortunately. i can't just tell people that i'll need to reboot every few days <dstolfa>obviously every system i manage has guix on it, even if it's a foreign distro <wirez>wait so you can't even choose when you reboot? <dstolfa>unless it's FreeBSD... then i don't have guix :( <the_tubular>But yeah, I think Guix would benefit a lot from being more popular <dstolfa>wirez: yeah you can't just reboot timesharing systems whenever you want, people might be doing important things <wirez>dstolfa ya but i mean, are guix updates force pushed into systems and they reboot on you? <dstolfa>no, you can reboot whenever you want as a sysadmin, it's just that guix doesn't have a notion of "here's a kpatch for this kernel version to fix this annoying little security issue and you don't need to reboot" <wirez>can you choose to not receive updates until you want to next? <dstolfa>you can update your packages, but not your system if you want to <wirez>does rolling mean that i might update to something thta's now broken? <dstolfa>`guix package -u` vs `guix system reconfigure` <dstolfa>wirez: yes, but you can always revert to your previous generation and use that <luis-felipe>Does Japanese input breaks for you in Emacs everytime you upgrade your profile? <lispmacs[work]>luis-felipe: I have not been looking at any Japanese input, but I find I occasionally need to rebuild font database with fc-cache after an upgrade <PurpleSym>luis-felipe: I remember ibus keeps a registry in ~/.cache somewhere and updating your profile invalidates the paths recorded there. <luis-felipe>lispmacs[work]: In my case, there is no font problems though. The problem is, when I activate Japanese and type in Emacs, what I type is not converted to Japanese, I can only type latin characters... <luis-felipe>PurpleSym: Thanks. I removed ~/.cache/ibus, restarted Emacs, and now it works :) <jas>hi! the manual says 'Note: It is highly recommended to run guix pull once before you run guix system reconfigure for the first time (see Invoking guix pull). Failing to do that you would see an older version of Guix once reconfigure has completed.' <jas>However, I'm reading about --allow-downgrades and it suggests to me that the default behaviour is that 'guix system reconfigure' would never install an older version. Right? If so the first warning is a bit too strong. <the_tubular>If you don't guix pull, then guix system reconfigure won't know it's not the latest version <apteryx_>jas: tricky to see at first, but the guix package collection contains guix itself, used by the likes of the guix-daemon-service-type, which means if you've never 'guix pull'd and repeatedly run 'guix system reconfigure', you'll navigate the guix version history backward. <apteryx_>(since before the first 'guix pull', the guix refered to is the guix found in the system profile, which is pulled by guix-daemon-service-type) <jab>feel free to stop buy and ask questions <bmk>I'm noticing some weird behavior with some files recently, on GuixSD. They're there, I can see them in ls, cat them, but when a program tries to load them it's like they don't exist. Anyone else experience this, or have I goofed up something? <cbaines>bmk, are these a specific kind of file, or just files in general? <bmk`>I managed to lock up my laptop by catting another file <bmk`>so: thoughts? did I dun goof? <cbaines>is it a specific kind of file that can't be opened, or just files in general? <bmk`>Files in general. For example, was attempting to play good 'ol dorf hellhole simulator when first off: Downloaded a premade pack for the game, couldn't load files saying they weren't there when they appeared to be, now installed through a user channel and it says it can't find the music for the game, even though they're there and readable <bmk`>and it's not a problem with the game, as I accidentally proved <bmk`>It's programs reading some files <bmk`>which now that I think about it <cbaines>could it just be looking in the wrong place? <cbaines>maybe you can use strace to check what exactly it's trying to read <bmk`>I should mention this is also an encrypted disk <bmk`>It seems to be looking in the right paths having looked at it <bmk`>I'll try copying to an external drive and try on a known good machine <bmk`>It works fine on my non-guix machine <bmk`>so: what's different about guix that might cause this? Compared to say, arch linux? <cbaines>are there any shared libraries among the files it's trying to use? They're commonly a problem due to the embedded filenames <bmk`>It seems to try a few times with wrong paths before finding it <bmk`>Anyway, I'm going to go see if I can figure this out... It may just be that the ssd has reached the end of it's life, or there's some filesystem weirdness going on <drakonis>civodul: what does adding early cutoff to guix entail? design wise? <civodul>drakonis: i should write about it, but essentially, (1) the daemon would store hash-modulo-self-references for each store items, and (2) upon build completion, it'd check whether the result's hash-modulo-self-references is already known, and in that case, go on with grafting instead of building dependents <civodul>the nice property is that it wouldn't change the model at all: the store is still a memoization cache <civodul>(as input data to train its Copilot model :-)) <dstolfa>the_tubular: it's a bit hazy on what it means "a company to use X", often it's just people within the company that do it <drakonis>but is this going to be done in guile or c++?