<karhunkynsi>hey guys, i'm running through the installation and noticed a minor weakness in the "System Installation". In section 6.1.3-1 it says to use "eno1" for network interface, however this isn't always correct. <iyzsong>karhunkynsi: yes, there is a footnote for it, but I agree it could be better. <DusXMT>shiranaihito: It shoudln't be impossible to port it over, but for the time being, no. <shiranaihito>DusXMT: alrighty :) i wonder if the idea has come up before <DusXMT>shiranaihito: Certainly; there was a person who was considering doing a "Debian GNU/kFreeBSD" port, and a bunch of people thinking about an OSX port, but for the time being, the only actively developed port I know of is for the Hurd <DusXMT>(Except for GNU/Linux, of course) <mark_weaver>shiranaihito: if we did port it, it would only be to the OpenBSD kernel. the entire userland would still be GNU, from glibc up. <DusXMT>shiranaihito: It's a very interesting operating system <mark_weaver>and I'm not sure what would be gained by porting it to just the OpenBSD kernel. <shiranaihito>well it's interesting, but i can't imagine it's practical for getting stuff done.. i could be wrong of <DusXMT>And with each month, it's getting better and better. For example, someone just ported NetBSD's rump kernels over to the system, so the hardware support problem should be slowly fading away <DusXMT>Of course, work needs to be done to integrate them, but the hardest part, writing device drivers, is done by NetBSD ;) <shiranaihito>i'm basically clueless about how linux/unix works, so i don't know what it means to "only port Guix to <Kernel X>" <DusXMT>shiranaihito: the Rump kernels are a way to compile NetBSD drivers as userspace programs for different operating systems <mark_weaver>shiranaihito: ah, well, in that case it's probably simplest to just say "Guix doesn't run on OpenBSD" <shiranaihito>mark_weaver: it *is* possible to give me a more detailed understanding than "yes" or "no" though :P <mark_weaver>well, what I mean is that it would be a completely GNU system, and the only component used from OpenBSD would be its kernel. <shiranaihito>DusXMT: ok, whatever that means :P (but don't let that discourage you, Mark :p) <mark_weaver>so none of the other code from OpenBSD would be used at all <DusXMT>shiranaihito: How do you know my name is Mark? (well, Marek) <shiranaihito>DusXMT: i meant the "mark_weaver" Mark.. unless he's just someone who weaves marks :p <shiranaihito>when you say "a GNU system", is that related to the Stallmanesque "freedom" stuff? <mark_weaver>well, I was talking about the software, but we are also committed to the philosophy of free software here. <DusXMT>shiranaihito: It will use GNU utilities, GNU libraries (glibc, gnu bash, gnu coreutils) instead of the BSD utilities <shiranaihito>but.. why would the only thing used from OpenBSD be the kernel then? <mark_weaver>because we aren't interested in maintaining a system with BSD components <shiranaihito>is that because of the aforementioned philosophy, or.. ? <mark_weaver>it would be a huge amount of extra maintenance work, and for what? <mark_weaver>it's just that allowing the utilities and compilers and C library to be swappable would be a huge extra burden on us <shiranaihito>and i'm not saying i'm upset or anything.. just curious about stuff <rekado->shiranaihito: with Guix the complete dependency graph is captured by each package. It's a feature. <mark_weaver>I'm not upset either. I'm sorry if I came across that way. I'm just trying to clearly communicate what Guix is and what it isn't. <shiranaihito>so.. Guix can't be just like.. compiled into "an OpenBSD binary" and used like any ordinary application? <rekado->as a result, making stuff swappable at arbitrary points isn't trivial. <DusXMT>shiranaihito: It can be made to work on OpenBSD. It just won't come with the OpenBSD utilities as a part of what you can install from it <mark_weaver>when you replace lower-level components, lots of stuff on top breaks and has to be patched, in practice. <rekado->it's not so much about Guix as an application, but about the things you build with Guix. <mark_weaver>we have a focus. we are trying to build the GNU system. we are not trying to build something that can be used with arbitrary middleware components. <DusXMT>OpenBSD-based GuixSD, of someone made such a thing, would basically be, as some people say, "a Linux distro", with Linux removed and OpenBSD's kernel put in place, kinda like what Debian's doing with their GNU/kFreeBSD. <shiranaihito>DusXMT: what does it mean for "OpenBSD utilities" to be a part of what can be installed from Guix? .. i mean, Guix would be used to install stuff like third-party applications like servers and stuff, right? but to me, "OpenBSD utilities" sounds like "awk" and "sed" and the like <rekado->it's not impossible to swap out input packages programmatically, but this project hasn't done anything like that, has no capacities dedicated to make it work (because that's not the goal as mark_weaver said), and it's unlikely to just work. <DusXMT>shiranaihito: indeed, it is the "awk", "sed", "sh", and friends. There are various implementations of those utilities, each with different quirks and features, and if you change from GNU's implementations to BSD implementations in Guix, you'll find that many things will fail to build, since they might depend on specific behavior of the GNU flavors <rekado->shiranaihito: a package in Guix is fully defined by all its inputs; this includes the tool chain used to build it, the compiler, the shell, etc. <shiranaihito>well, are you guys "philosophically opposed" to OpenBSD? <rekado->so even if you build/install an application like a server, you'd still find --- somewhere at the bottom or during the build --- a dependency on tools. <DusXMT>shiranaihito: Why would be? It's free software <mark_weaver>in general, Guix doesn't use anything from the host system at all. even if you run it on another GNU/Linux system, it doesn't use *anything* from the existing system except the kernel. <mark_weaver>it starts with bootstrap binaries that we provide, which include a compiler, C library, and some GNU utilities <DusXMT>shiranaihito: it comes with its own <mark_weaver>and then it uses those to build the GNU system from the ground up. <mark_weaver>you can skip these steps by using our pre-compiled binaries if you like <shiranaihito>is the "GNU system" considerably different from various Linux distros and OpenBSD then? <DusXMT>shiranaihito: The GNU system is basically what certain people call "Linux" <shiranaihito>anyway.. when you say it comes with pretty much everything it needs included, it kind of sounds like it could be used anywhere <mark_weaver>so-called "Linux distros" are distributions of the GNU system <mark_weaver>except for Android, which uses Linux (the kernel) but nothing else from GNU <DusXMT>shiranaihito: Indeed, that's why I said that it _would_ work with OpenBSD, it just wouldn't come with the BSD utilities <shiranaihito>well, i seem to recall "GNU Linux" vs "Linux" being some sort of ideological distinction <mark_weaver>it could work with the OpenBSD *kernel*, but it would have to be ported to it, because our bootstrap binaries are built to run on Linux (the kernel) <DusXMT>shiranaihito: not really. GNU/Linux - GNU System which uses Linux as its kernel; Linux - A monolythic, unix-like operating system kernel written by Linus Torvalds, and a huge-ass community that surrounds him <shiranaihito>so the main problem would be getting all the OpenBSD packages to work with the GNU utils that Guix uses.. or something? <mark_weaver>shiranaihito: there are many components of an operating system. most of the core components are from the GNU project. it's the GNU operating system with the Linux kernel added. but many people just call the entire system "Linux". <DusXMT>shiranaihito: no. The problem would be getting the bootstrap binaries to build <DusXMT>And to ensure that the Guix daeomn and client work properly on OpenBSD <mark_weaver>that's not about ideology, it's about giving credit to the ones who actually made most of the core system. <shiranaihito>so a "GNU system" is.. any kernel with the GNU utils around it, or a Linux kernel specifically? <mark_weaver>any kernel with the GNU compiler, C library, utilities, etc, around it. <rekado->the value of the GNU C library is often under-appreciated. <shiranaihito>well, i wonder if i'll have to make do without OpenBSD, or without Guix then :P <mark_weaver>from the point of view of most of the software on the system, and from the point of view of the user, the kernel is almost irrelevant, a component buried deep down. <DusXMT>and abstracted away by the C library <mark_weaver>the API that most software cares about is the C library, the compiler, and the other libraries, etc. <rekado->shiranaihito: if Guix were ported to OpenBSD you could still package up BSD software for Guix, of course. <rekado->but the porting part should not be underestimated. <_`_>shiranaihito: if you just want stuff to work “and get stuff done” an adventurous project like GNU Guix on OpenBSD sounds like a deterrent for that goal. <mark_weaver>shiranaihito: let me ask you this: why do you want to use OpenBSD? I'm not asking to try to convince you otherwise, but rather to gauge whether Guix on OpenBSD would still hold the benefits you desire. <shiranaihito>_`_: well, there's no adventure if whatever i'm using Just Works.. that would be the goal here anyway <DusXMT>shiranaihito: what _`_ meant to say is, this port would be a lot of work :) <shiranaihito>mark_weaver: it seems to me that OpenBSD is very sensibly managed, and reliable.. potentially with minimum fuss and breakage etc <mark_weaver>if you want stuff that "Just Works", then Guix on OpenBSD will certainly not accomplish that, and even existing Guix wouldn't. we are in an early stage, and lots of stuff doesn't work properly yet. <_`_>have you used OpenBSD? <shiranaihito>i'd like to use Guix too.. which is why we're having this conversation :p <rekado->re "sensibly managed, reliable, minimum breakage" --- I found that the Guix System Distribution (GuixSD) matches these terms, in my experience. <shiranaihito>yep, GuixSD may well be great :) i like OpenBSD's security-oriented approach too though <DusXMT>shiranaihito: Guix is alpha software. If you want something which Just Works(tm), Guix won't fit your needs :) Stick to OpenBSD, you'll get the BSD utilities and nice features like 64bit time_t on 32bit systems, libressl, packet filter, and everything else out of the box <_`_>Someone with experience with both (experience being key here) might have various degrees of success with GNU on top of OpenBSD. Whether the GNU C library and other userspace components work just fine on top of OpenBSD, compared to what OpenBSD ships with as an OS, is an experiment for a person wanting to try this. <shiranaihito>but from what i've seen, i'm not happy with the typical Linux distros.. and not happy with at least one not-so-typical one: ArchLinux <DusXMT>shiranaihito: Gentoo is really nice in my opinion, have you tried that yet? <_`_>And that's not even taking into account GNU Guix as a package manager. Or possibly shipping what's part of OpenBSD's userspace with GNU Guix and getting that working instead <shiranaihito>basically i'm trying to choose the most sensible and practical tools for running my future SaaS apps <rekado->I used Arch before and eventually switched to Fedora after stuff broke with every update. (e.g. input methods). Now I'm with GuixSD and no longer worry about upgrades at all (because I can always roll back.) <shiranaihito>ArchLinux is out because running "pacman <upgrade stuff>" totally borked the Arch installation.. that's just.. ridiculous <shiranaihito>btw, i didn't even use Arch for long.. and still saw that kind of problems <shiranaihito>the open source world is full of half-assed solutions.. which is why OpenBSD is appealing <shiranaihito>mark_weaver: i may do that.. but now i'm trying to figure out if i'd be losing out on too much without using Guix <_`_>You have to try these things yourself if you aren't going to pay attention. <rekado->it is true, though, that you'd have to try things by yourself. <_`_>Learn from experience. <rekado->while the core system is maintained as a whole in the BSDs, this may not directly translate into a better user experience. <shiranaihito>rekado-: of course, you'll always learn from experience.. i'm just trying to minimize the "learn the hard way" -part of learning from experience <_`_>It just seems a bit negligent to ask some of these questions without having any insight as to the issues such a desire may lead to. <_`_>GNU Guix on top of OpenBSD. <_`_>(tbf, I'm interested in a slightly similar idea, but I've made myself completely aware of the issues surrounding such) <shiranaihito>you've told me it doesn't work on OBSD without a lot of effort that people probably won't be going to go through.. so Guix on OBSD is out <shiranaihito>i'm interested on GuixSD too though, now that you've brought it up.. if it really is similar to OpenBSD in the way it's managed and developed etc <rekado->"similar" is probably not a good term. <rekado->every GNU/Linux distribution takes software they didn't write and put it together in a certain configuration with certain defaults and some glue. <rekado->the goal is a consistent system, but the way to get there differs. <rekado->the way GNU/Linux distributions are assembled is very different from the way the core of BSDs is built. <rekado->if you focus on the user side, though, I think functional package management has a very tangible benefit. <shiranaihito>well apparently there's shitty glue and good glue, and something in between <rekado->as I wrote earlier, Guix packages close over the complete dependency graph, all the way down to the kernel headers. <rekado->Guix is a very interesting and reliable framework to build a system on. <DusXMT>Arch has a large community of loyal users around it, and I don't think they'd be hailing a "turd" if it was _that_ bad... <shiranaihito>or more like irrational and emotionally attached to things/ideas <rekado->shiranaihito: I don't think it is helpful to talk about Arch here, honestly. We know more about Guix ;) <shiranaihito>but basically a big community isn't a sign of good software <shiranaihito>well, now i was talking about things that are (or can be) involved in any project :P <mark_weaver>shiranaihito: one thing you ought to know right now is that we're dedicated to the goals of the free software movement, and building a 100% free system complying with the GNU Free Software Distribution Guidelines. <shiranaihito>i used to think Stallman was kind of um.. "overboard" with the stuff, but these days it's clear it's not possible to be too careful .. or at the very least it's great that some "truly free" stuff exists <shiranaihito>maybe i'll play around with GuixSD a bit.. is it reasonably painless to get it running on a VPS? <mark_weaver>there's still a lot left to do to make GuixSD good for running servers. <mark_weaver>it's a good foundation, but we still have very few service definitions <mark_weaver>so far we've been mostly using it for desktop systems, and it needs work there too :) <mark_weaver>so if you want something that "just works" "today", you'll be disappointed, I'm afraid. <mark_weaver>that said, if you're willing to do a lot of fiddling and troubleshooting at first, and live for now with some inadequaciees (or better yet, help us fix them), then it's quite reliable in the sense that you can prevent regressions using our roll-back features. <mark_weaver>it's the first system I've run that is both cutting-edge (using very up-to-date software in most areas), and also reliable (no fear of being left with a broken system from a bad upgrade). <mark_weaver>Nix also has those properties, but I prefer Guix for both technical and philosophical reasons. <rekado->note that you can use Guix on top of other GNU/Linux systems. <rekado->for me roll-back and software profile management are very important features, so I use Guix at work on top of conservative server distros. <civodul>could someone look at the patch series of Eric Dvorsak and push those that are OK? <civodul>maybe bavier, since you started already? :-) <civodul>we should reduce review latency for newcomers, to not drive them away <karhunkynsi>just thought i'd mention. After an apparently successful install i can't boot from usb and get to the prompt anymore. I get passed the bootloader, then i get this error for a few seconds: "error: file /gnu/store/..-system/initrd not found", then it crashes <mark_weaver>civodul: along the same lines, if you could look at wingo's patches, that would be great. I tried but felt that my expertise in those areas is not sufficient.. <civodul>mark_weaver: yes, i'm planning to do that <civodul>karhunkynsi: could it be that you used "gnu-disk-image" as the label of your root partition? <civodul>that's the label where the USB installer expects to find its root <karhunkynsi>if that's the default, then yes. I didn't change the label <mark_weaver>ACTION sends the first batch of GuixSD-on-MIPS patches to the ML <sneek>Welcome back davexunit, you have 2 messages. <sneek>davexunit, paroneayea says: One crazy way maybe to have different objects communicate things between ticks and still keep things functional is a pseudo-functional pseudo-actor model where npcs / player objects and etc first process the current game state, then generate possible messages to be read by other actors during this tick based on that state... maybe? <sneek>davexunit, paroneayea says: I guess that deviates more from the FRP direction than you want to go, though. <DusXMT>ACTION should check the state of GNU/Linux on PS2, if that's still around, he might end up trying out Guix on MISP ***ar is now known as null
***null is now known as ar
<bavier1>mark_weaver, civodul: I'll look at Eric Dvorsak's patches for xmonad <bavier1>Is it fine to adjust patches for minor spelling/formatting changes? <civodul>bavier1: IMO yes, at least for newcomers <civodul>i usually tell which changes i made when i do so <bavier1>133 new GHC module packaged for git-annex :P almost there <civodul>that plus xmonad, that's a lot of Haskell :-) <bavier1>(I meant earlier: I'll look at Siniša's patches for xmonad, and Eric Dvorsak's for i3-wm) <bavier1>btw, should we start a gnu/packages/wm.scm? <bavier1>actually, I didn't realize how many window managers we already have, many of which are in their own modules <bavier1>but perhaps moving foward it would be best to consilidate a bit ***ar is now known as null
<bavier1>I discovered that our ghc packages retain references to test-only modules <bavier1>I think most references come in the "package.conf.d" files that are installed <bavier1>I'm not sure those files are even used <bavier1>if they were, I'd think GHC would be able to find dependent modules without our needing to propogate them all <civodul>mark_weaver, iyzsong: looks like the PAM patch can be installed right away! <civodul>sprang: can you edit gnu/build/file-systems.scm and "raise" the expression in the eval-when form?