<civodul>or rather, which problems did you encounter? ;-)
<jgrant>Yeah, actually. It has a weird issue where it's not picking up my patch via root (the use-whatever-modules), but will as a typical user -- when rebuilding my config. ACPI complains about missing a package, ocassionally in my ttys.
<rekado_>huh? No, I was annoyed by the discussion on gnu-system-discuss (especially when GSD was deemed a "confusing" abbreviation). I only suggested a different interpretation of the abbreviation. Other than that my participation in the discussion was completely passive.
<taylanub>ah ok, I think I confused you with another
<jxself>"i think an external observer would find it incredible that we even stay within GNU after all that ;-)"
<civodul>it seems there's no consensus on which approach to take
<mark_weaver>taylanub: I think that's for historical reasons. long ago it was more efficient to do so. now I think it doesn't matter much efficiency-wise, but using a ramdisk is a major lose when you try to put a lot of stuff in /tmp (as we do)
<mark_weaver>if we don't clean up /tmp, then users will have to do it manually. seems bad to me.
<taylanub>I agree we should clean it up (not sure if there's systems that don't do that at all)
<jxself>Okay, so a lack of entropy is probably not the reason then.
<mark_weaver>jxself: btw, my X60 running your kernel often freezes for times on the order of 1-2 seconds. I've generally not experienced this on Debian or other systems. I wonder if it's due to your kernel config or just that it's a much newer kernel than I run in Debian systems. any ideas?
<ams>one should use urandom under all circumstances
<mark_weaver>jxself: I notice that you use the deadline schedulers, whereas I seem to recall debian using CFQ. maybe related?
<jxself>taylanub: Although urandom produces lower quality random numbers.
<ams>nor is urandom a false RNG .. the two are exactly the same
<taylanub>the only time Linux's urandom device gives lower quality randomness is right after boot and if init scripts haven't seeded it with randomness stored from the previous shutdown (note implications on first ever installation of a system :P)
<jxself>It would be interesting to know what else is going on at the time.
<Soft>Does anybody have an idea how I could create a service for setting up dbus desktop session, I mean It would probably have to call dbus-launch, capture the environment variables it outputs and then inject them to all the other services that depend on it
*jgrant is trying to figure out how to set up GSD on his Linode instance the easiest way possible -- and was thinking he might just emulate what he did yesterday, with bootstraping via Parabola. NixOS has a relatively simple method though, via https://nixos.org/wiki/Install_NixOS_on_Linode
<pecg>mark_weaver: Please don't kill yourself, there is a lot of things to do with your life, whatever you decide is welcome except writting proprietary software, and other kind of slavery
<jxself>How'd we get on this topic anyway? Is today "Bash on emacs day"?
<ams>jxself: it started with the absurd claim that emacs was one of the most well engineered programs ever written :-)
<jxself>Ah. That is probably a matter of protracted discussion for any program.
<jgrant>jxself: My assumption was in-reference to the name of Ludo's FOSDEM talk.
<jgrant>I can't find anything else prior to this direction to Ludo, that may have sparked it.
<ams>alot of design mistakes exist in GNU emacs... worked around haphazardly
<pecg>ams: I guess you could write a better replacement for it. AmsEmacs, maybe?
<ams>pecg: that is a silly way to have a dicussion
<rekado_>rms says in the paper: "The development of EMACS followed a path that most authorities would say is a direct route to disaster." and "While there was no overall goal, each small change had a specific purpose in terms of improving the text editor in general use, and each step had to be individually well designed and reliable."
<pecg>ams: I guess it is, that's because I replied with the 'because it is the truth' argument.
<jgrant>Like the technical design of Emacs or not, it's more so about the general design philosphies rather than the actual implementation, that Guix and other projects like it should adopt. :^P
<ams>alas, all those small steps amount to lots of bad decisions ... like single threads, a quite crappy lisp for over 30 years, and what not
<jgrant>This is getting offtopic, with only a tangential conenction at best though to Guix.
<jgrant>Yeah, tomorrow I'm going to bugger about with getting GSD on my Linode via some means. All I really need is Nginx and Emacs right now, and the former doens't even need a service really for right now.
<jgrant>I mean, it's very hard to estimate pepole's interest to a point where they will install/try such a thing on their old box -- but I assume that there is currently like what, 50 semi-frequent Guix users overall (again, all conjecture too -- but "feels in the ballpark").
<mark_weaver>it would be one thing if I could actually talk to him. I would much prefer to do that.
<ams>clearly there is some communication error somewhere
<bavier`>under "substitutes" in the manual: "To allow Guix to download substitutes from hydra.gnu.org, you must add its public key to the access control list (ACL) of archive imports, using the guix archive command"
<ams>i installed guix 0.8 on a usb stick, ran the noted commands, and cannot install emacs because of various reasons
<ams>bavier`: yes, and why the fuck should i need to know that to install a package? are you really suggesting that every user has to plough through the whole manual, understand every single sentence to install guix?
<nully>we can probably extend that volume, no biggie
<rekado>ams: you do not *need* to use substitutes, but you can enable them. So you don't have to "plough through the whole manual, understand every single sentence to install guix".
<jxself>Although not compiling everything from source is probably faster. ;)
<ams>rekado: sighs, look .. following the instructions, from installing system to system configuration, there is nothing about substitutes, zilch, zero, nil and null. i don't even have a clue what they are after having read the chapter on them, but that is a different topic. the point is that the manual is lacking severly in how to install guix, how to even install a single package without ripping your hair out, it is
<ams>i know you peeps don't get paid to work on savannah .. but might be useful to be on that list at least
<rekado>ams: well, yes, because you don't actually need substitutes to install the system (it'll just be a source install then). They are nice to have, though, so they are prominently featured in the manual.
<rekado>ams: doing package management also has its own section in the manual. It doesn't belong in the System Installation section.
<rekado>ams: I really think you should stop ignoring mark_weaver and davexunit (I consider ignoring them to be very rude); mark_weaver has already applied the patch by phant0mas, so pulling should be okay.
<rekado>ams: on the subject of substitutes again: when enabled you can download pre-built packages instead of having guix compile them for you. They are enabled by default in GNU GSD from 0.8.1 onwards.
<ams>i consider their behaviour to have been far ruder than putting them on ignore, i might do it tomorrow. maybe. now, some knitting ...
<bavier`>ams: your method may not work. I don't think it'll download source that's declared as a package input. E.g. texlive has the texlive-texmf-src input, which will not be fetched with `guix build -S ...`
<svetlana>sorry, i was adding noise. i will return later.
<jgrant>Wow, that was an insane and inane backlog.
<jgrant>ams: It's important to specify that this is alpha software, because things may not work out of no-where. I installed GSD on my main box yesterday, and had no issue with the bootstrap, then pulling that fell after.
<jgrant>Someone made a patch in the time between then and now that had the wrong hash, and made pull fail. It was identifed, patched, and is soon to be fixed.
<ams>civodul: and you please assume good faith, i've been accused as a liar
<civodul>ams: certainly not, because nobody behaves this way on this channel
<jgrant>I don't see the point of having an "Stable" branch as is, right now since it *is* Alpha Software and all assumed users are to have a certain level of technical skill to be able to debug such trivialites.
<jgrant>ams: I want to be clear, it's not a design flaw -- it's a lack of implementation to resolve an issue due to not enough desire by said community to maintain a solution as of current. A design flaw denotes there is a fundemental issue with the structural and/or actual design in which the program was made. I don't want to argue this, I can't see a future where GSD won't get a Stable branch -- it's just not something as Alpha software, that
<davexunit>tl;dr - we're iterating a lot right now. things change and break. :)
<ams>jgrant: currrently there is a fundamental issue with it, so yes, it is a design flaw, however easily fixesd
<davexunit>now we're in pedantry territory. best to drop it.
<jgrant>ams: It's important to be civil in these conversations when possile and it's hard to stay as such when someone is making assertions that is abusing the common speak as people are used to hearing. This could have gone a whole hell of a lot better, of you phrased this better and more clear. I have this issue often, I was called out for it the other day -- live and learn.
<jgrant>It's also a hard skill to build up, obviously, too.
<ams>jgrant: i phrased things quite clearly, maybe people here should be more civil.
<jgrant>But again, yeah, might as well move past it.
<ams>jgrant: and your accusatory tone is not welcome
<jgrant>ams: I'm not attacking at all; I said I was shocked by the backlog I was skimming. And that I think Alpha is a fair label to not assume perfection. But again, I'm done -- if you want to feel attacked, it's within your rights to do so.
<jgrant`>Well, maybe this is more helpful than I think ... but all it says (right before it tries to open a guile prompt), is "ERROR: In procedure symlink: " followed by "ERROR: In procedure symlink: File exists".
<jgrant`>File name of what, where the syslink supposed to point?
<mark_weaver>any filename that might be associated with that symlink attempt would be helpful
<jgrant`>Also, yeah -- there are a bunch of backtraces. You know, it might be because of that usb module that was just added. Looking at this screenshot, all backtraces are related to Usb something or another...