<gazon>CharlieBrown: I don't know. The speaker (that link is a presentation slide) was talking about FSF endorsed distros being the most resource constrained link in a chain of security updates from source to user. Those distros are less secure as a result.
<buenouanq>You're missing out as is though just for the mere fact that you don't know Scheme ┐( '~')┌
<gazon>buenouanq: true on both counts, but I still need to be able to build software, fire-up virtual machines, etc. and it seems to me that if I need a package in a hurry then I need to known guile to get one made.
<reepca>Hm, unfortunately they aren't quite certain where the balance between "too hard" and "can't fill a summer with it" lies. Both because they aren't certain of their skills and because they aren't certain of the difficulty of the tasks.
<reepca>The build tool seems like it would require the least specialized knowledge, but I don't have a very good idea of the scope of the project.
<reepca>Specifically regarding the build tool, it says "... should ultimately be able to run complex workflows on multiple servers and...". What exactly is meant by that? That the build process should be able to be distributed across servers?
<janneke>reepca: I guess, but better ask later when more of GMT+1 is awake ;-)
<reepca>Alright, I've just got myself in a bit of a pinch here with delaying so long getting this stuff figured out.
<janneke>but esp. wrt to your remark of striking the balance, I believe that if someone chooses a project that they really want to do, they can accomplish amazing things -- whereas when it's `just work' they will `probably do okay'
<janneke>and there are mentors to help with any questions, of course
<ZombieChicken>OriansJ: Yes, but suggesting a constantly dwindling supply of outdated systems doesn't help matters. Better to spend the money on open hardware and non-x86 systems than sinking it into old, refurbished hardware
<OriansJ>ZombieChicken: That is why RISC-V Systems are being developed
<braunr>if that non-x86 system is actually more advanced than the old refurbished hardware
<ZombieChicken>I understand why old hardware is suggested, just stating that the money is better put in other places
<braunr>people seem to severely underestimate all the research put into that old and quirky total-store order architecture in order to make it that fast
<janneke>ZombieChicken: won't that take some time?
<ZombieChicken>OriansJ: As I understand it, RISC-V isn't there yet, and I'm not aware of a production-ready system that's using it
<OriansJ>ZombieChicken: Some people want freedom now and that might consume some money that might be better invested for freedom later but that is their choices
<ZombieChicken>janneke: Time and money, but I'd hazard a guess and say that money is one of the bigger problems
<janneke>aren't those the options: spend money to get freedom now, invest money to get freedom later?
<braunr>what's the problem with the old vikign stuff ?
<OriansJ>ZombieChicken: There are no "Clean" solutions, only a community trying things together
<braunr>OriansJ: i don't mean to be harsh, but i really don't see how those proverbial answers could help anyone :/
<ZombieChicken>1) it's already outdated, so if something goes wrong finding a replacement will become steadily harder, 2) unless you're unfortunate enough to have a "modern" ME-included system, you're better off spending the money on something with a future, like ARM or whathaveyou
<braunr>1/ is countered by the fact that lots of those are still around, well supported
<braunr>they're actually reference platforms for "outdated"
<braunr>2/ no, the future is full of bugs, if you want something that works, you want old
<ZombieChicken>braunr: Regarding your previous comment about x86 parrellel code blowing up on ARM, is that absolutely a flaw in ARM, or a flaw in execution (either from the compiler, interpreter, or programmer)?
<OriansJ>braunr: PL/M was always much better for writing low level software. Lisp was better for high level and dozens of others have better fits all over the place but C was the one which was made by Unix.
<ZombieChicken>Never a good sign when I run a command and it fails, then rerun it instantly afterwards and it works fine
<braunr>OriansJ: i don't know pl/m enough to agree on that
<ZC-wuz-hur>glxgears worked fine, and extremetuxracer worked
<OriansJ>ZC-wuz-hur: just turn up warzone2100's settings
<ZC-wuz-hur>I'm installing minetest, chromium-bsu, and warzone2100 atm
<ZC-wuz-hur>If this works, I just need to figure out RAID and LUKS and I should be set
<ZC-wuz-hur>and hopefully everything else I want to run with play nicely
<CharlieBrown>I'm trying to put GuixSD on a multiboot ISO but the installer image is not an ISO and IDK how to extract it and look at the grub.cfg.
<ZombieChicken>yay. apparently the open-source nVidia driver won't work for me
<reepca>Regarding the build tool in the GSoC suggestions, it says "... should ultimately be able to run complex workflows on multiple servers..." - what exactly does that mean? That the build process should be able to be distributed across systems?
<lfam>reepca: You might have better luck starting the discussion on the mailing list; the Guix developers interested in that project may not be on IRC right now
<marusich>CharlieBrown, if you want to examine the grub.cfg which got generated for the installation image (which, as you correctly pointed out, is not an ISO-9669 file system image), one way you can do that is to mount the image as a loopback device, and then examine its file system like any other.
<marusich>If you plan on using GuixSD in a multi-boot situation, you should be aware that changes which update the grub.cfg file might blow away any customizations you have made to accommodate the multi-boot setup.
<marusich>(i.e., 'guix system reconfigure' and the like)
<roelj>It seems that when I try to compile Guix with Guile 2.2, it cannot find the gnutls guile module.. Is this a known problem?
<janneke>roelj: yes you need to install guile2.2-gnutls (or gnutls/guile-2.2)
<kadintrooper>If I wanted to symlink python3 to python how would I go about that
<lfam>kadintrooper: If you are asking about doing that within the context of Guix packaging, use the package python-wrapper