IRC channel logs
2025-01-13.log
back to list of logs
<mightysands>Hey, I'm running a thinkpad T60 (32-bit i586) and am thinking about getting a new Milk-V Jupiter (a new 64-bit risc-v mini-atx motherboard). I'm thinking about moving to guix, but I've heard that one can run guix on hurd now ! I was wondering if hurd with guix might work on my T60 or the Milk-V Jupiter ? Or if this is still early to attempt something like this <mightysands>I've heard that filesystem or swap encryption doesn't yet work with the hurd (?) <youpi>nobody contributed it so far indeed <youpi>it would probably be a matter of a libstore layer <damo22>you cannot run guix on hurd as there is no port to riscv yet <damo22>you may be able to run hurd on guix though <damo22>i wonder what kind of arch specific code needs to be written to port hurd to riscv <youpi>similar to arm64 essentially <damo22>i havent seen that in the tree yet <damo22>sneek: later tell solid_black what is the status of arm64 hurd port? <mightysands>hurd is the kernel, how could the kernel run on top of an OS (guix system) <damo22>mightysands: as in, run it as a childhurd which essentially is a qemu layer , hurd is an OS, gnumach is its kernel <damo22>basically nobody ported gnumach to riscv yet <mightysands>so guix can run childhurds even if guix is built on top of a linux kernel, not hur ? <damo22>yes, its a vm essentially, as you said <mightysands>alright, thanks. from the readin I've done, I've also discovered that for some reason, guix and hurd haven't got desktop envs working yet so for now it looks like I'll probably go with guix and a linux kernel <damo22>hurd has Xorg if you can run VESA <mightysands>guix refers to both guix the package manager, but also guix system, the distro <damo22>ok i wasnt aware they rolled it into a distro <mightysands>I know, they don't make it very clear :P for clarification, during this conversation I have been referring to guix-system as guix. <mightysands>with this in mind, does this change anything about the context of what you said earlier ? <damo22>so you can have guix distro with linux kernel, or guix distro with gnumach kernel <damo22>the latter gives you a native hurd system <damo22>until the rest of the ISAs are ported <damo22>yea, but you mentioned upgrading to riscv <mightysands>But it's my only device atm, so I'd kind of need video drivers and desktop environments <mightysands>yes, though I was asking as to the possibility of running hurd on either my current thinkpad or the risc-v computer I'm looking to purchase soon <damo22>ok if you are running vendor bios, you can install hurd natively on your T60 and have Xorg <damo22>yes it has been reported to work <youpi>Xorg has been working on GNU/Hurd for a couple decades at least <mightysands>hmmm, that confuses me a little. this article here said that desktop environments and Xorg aren't working with guix on hurd... <youpi>perhaps guix doesn't have it packaged properly <damo22>mightysands: if you really want guix on your thinkpad perhaps you will get more help in #guix <mightysands>I was just thinking about asking the users there about this <mightysands>I'm interested in using hurd, but for some reason I've never liked debian or arch <mightysands>I'll head on over to #guix and ask around. Thanks for the help <damo22>the thing is the development is mainly done using debian/hurd so we know the limitations quite well here <homo>mightysands I wouldn't expect graphics drivers from small communities (except for select few cards), they are just extremely complicated <homo>also the reason you can't have graphics on guix most likely has something to do with optional dependencies that always get included for full feature experience, but those optional dependencies are incompatible with hurd <youpi>doesn't guix propose options in packages? <homo>never seen those, had to give up on building certain packages myself because of optional dependencies and test dependencies that I don't even need <mightysands>I'm considering using guix because of some security gripes I have with slackware, but what I really love about slackware is the packaging system and how user defined it is <mightysands>if guix is more controlling and less free than I thought then that's a shame. I thought it'd be more open <homo>"force" sounds too violent, it's just there is no proper code structure to avoid skipping optional dependencies without you modifying package definitions yourself <mightysands>homo: in slackware we have to write our own package building scripts in bash. Would it be more involved than that ? <homo>if all optional and test dependencies were skipped, a lot of other people would be unhappy who want more features, and guix was never meant to be minimalist <mightysands>Interesting that you say that concerning minimalism. The slackware base install is too big to fit on a dvd nowadays as of the 15-stable release, but having just checked, guix is less than 1Gb in size <youpi>uh? debian's netinst still fits on a CD <mightysands>damo22: I think I'll go with the Jupiter. It's cheaper and the form factor better suits my purposes <damo22>yeah but the instructions for the bigger system give you an idea of what is needed to make it boot <homo>in guix everything is written in guile (took nix daemon and ripped-off nix language because guile is identity of gnu), but there are abstractions to avoid repetition, like if to build you need "./configure && make -j4 && sudo make install", that is already automated for you <homo>haskell, rust, meson, cmake and others are also abstracted to avoid repetition <homo>still, for best hurd experience, you want a distro totally dedicated to hurd, otherwise you will always suffer the problem on guix that packages which work with linux-libre don't work with hurd <mightysands>I was under the impression that guix is aiming to be totally dedicated to the hurd <homo>unless there are enough maintainers and proper quality control to make sure no update breaks anything on hurd <youpi>guix is really a linux project mainly <youpi>there are some people who port guix to hurd, but it's really not the main goal of guix <youpi>you will even find a few people who think that gnu/guix/hurd is the heaven that everybody should strive for <youpi>but they are really not many :) <mightysands>I was under the impression that gnu/guix/hurd was perhaps...the future ;_; <youpi>it can be if people put energy and time into it <youpi>really, if people want something, they just have to work on it and they'll get it <youpi>I so often read people writing about hoping this and that to happen <youpi>things don't magically happen <youpi>it just requires people working on them <mightysands>homo: a slackbuild script is usually about 200 lines of bash. Would you say ommitting optional deps in defining a guix package is more involved than that ? <mightysands>I'm trying to consider if that'd be more, or less work for me <damo22>mightysands: read the source for the package description <homo>to your disappointment linux is "good" enough to prevent contributions to hurd, even though someone must actively remove blobs to provide linux-libre, hurd "died" the moment linux was released under gpl <youpi>it's not so simple, you will also find people working on bsd, haiku, and whatnot <youpi>hurd was very much not dead at all between 1992 and 2000 <youpi>there were even a few people paid full-time on it <homo>mightysands, for generic (autotools, cabal, cargo, cmake, meson) you don't need more than 50 lines of guile <mightysands>well the recent work is inspiring and I hope that I might find time to learn a thing or two about kernel dev in the next year or so and can contribute in a small way <youpi>it's only that the hurd name has been taken as a label for vaporware <youpi>without any actual reason for that <mightysands>homo: thanks. So making a package YOUR OWN way in guix is less work than 200 lines of bash it seems <damo22>kernel dev isnt really needed much, we need userspace drivers <mightysands>I know nothing about firmware and drivers and it'd help me more in future to know more about it <homo>youpi still, without linux kernel, what kernel would fsf and gnu use? would they strip blobs off haiku and bsd kernels instead? <youpi>that's better for long-term licensing than a gpl2-only kernel <youpi>my point is: it's no the presence of linux that prevents people from hacking on non-linux kernels <youpi>even if of course that'd reduce it <youpi>I just mean it's not a full-stop excuse <homo>mightysands well, participating in hurd development to learn writing drivers and firmware is more realistic than using it as your daily desktop <damo22>one day i hope to use hurd as my daily desktop <damo22>but until then i need to help make that into reality <homo>although you might use it as your daily desktop today, if you are willing to give up a lot of conveniences, there are people who enjoy such lifestyle, as there are people who seriously use plan9 on their desktops and even on their servers <damo22>im getting close to having a serious laptop able to develop hurd on hurd <homo>Ori Bernstein can't even provide help with plan9port because he uses plan9 exclusively <damo22>i cant seem to receive any packets except the ones i send <homo>if plan9port's file servers are going to be run as hurd translators instead of sockets in /tmp, that already makes hurd more valuable than linux and bsd <homo>it's a port of plan9 userspace to posix system, plan9 is created by same people who created c and unix <homo>s/posix system/posix systems/ <damo22>what is the use of it if we already have a userspace for hurd? <homo>plan9port is for people who like plan9 and can't have daily lives without its userspace (addicted like me) <homo>stereotypically plan9port is bootstrap for acme (ide) and sam (ed on steroids) <damo22>is it a different binary format? <homo>plan9 was designed for graphics and networks, with namespaces and 9p protocol it arranges network-transparent clusters of computers with completely different instruction set architectures and even with completely different operating systems <homo>plan9 kernel has about 50 syscalls, almost all of which are dedicated to 9p protocol <youpi>AIUI plan9port can be built as ELF binaries <damo22>so we could make a plan9 "kernel" in hurds userspace <homo>plan9port binaries are elf, but plan9 itself doesn't support elf, because elf is harmful <homo>but that format is completely irrelevant when communicating over network, irc server doesn't care whether irc clients are a.out, pe, elf or whatever else binaries, irc clients don't care as much about irc server either <damo22>id hardly call elf harmful, it might be slow i dont know <youpi>loading dynamically-linked programs sure has to be slow, you can't have the benefits without the costs <homo>shithub is a git hosting running on top of plan9 using only shell scripts <youpi>if you want to avoid that you can link statically <homo>plan9 doesn't support dynamic linking either, because dynamic linking itself is harmful <youpi>rebuilding the world to update a library also is harmful <youpi>anyway, we're really down to trolls there <damo22>well we're not ditching elf or dynamic linking anytime soon <homo>guix rebuilds world to update dynamic library, not much different <youpi>distributions most often don't <damo22>i update one dynamic lib at a time when im testing a change <homo>how else do you guarantee that it builds and builds reproducibly without rebuilding entire world? <homo>also entire plan9 system builds in 2 minutes, where linux kernel itself builds in 6 hours <damo22>the dynamic lib links at runtime so you dont have to rebuild world to change one lib <youpi>see e.g. ocaml or haskell do it <homo>a guix package is a checksum of all its dependencies, updating even dynamic library, and even a compiler, causes a change in checksum and thus triggers rebuild <youpi>which is a huge hammer for what you actually need <damo22>homo: if thats true, guix sounds wasteful in compute <youpi>with C's difficulty to grasp ABI, it's not really surprising <homo>it is, but every binary must correspond to specific source to promise reproducible builds <damo22>how does plan9 kernel expose devices? <homo>plan9 file server is what in hurd you call translator, because of namespaces /dev is a union mount of file servers provided by both kernel and userspace, furthermore they all can come from completely different machines <homo> /dev/audio can be audio server (like jack), or remote computer's speaker or your laptop's headphones, it doesn't matter as api/abi/protocol are always the same <damo22>what keeps track of the dev nodes? <homo>plan9 kernel is responsible for providing 9p, namespaces and syscalls for those (about 50 syscalls in total), it multiplexes them <homo>namespaces are per-process, every process sees /dev differently <homo>it's not just /dev, it's literally everything is namespaced <homo>instead of PATH env variable, /bin is a union mount <damo22>if we ported plan9port to hurd, the end result would be a set of ELF binaries, does it include a port of the kernel? <homo> /dev/draw is screen or window, either on your computer or on some else's computer, but your programs don't need to know that, /net in your laptop can be a mount of router's /net to bypass nat, or even vpn, or even proxy <youpi>I don't think we'd need the kernel <youpi>just a library-based 9p protocol implementation on top of mig <homo>plan9port is userspace without kernel <damo22>we could put plan9port's dev in /dev/9p/... <homo>it's ported without Ken Thompson's assembler and c compilers and linkers, those don't support elf <homo>in other words it's slightly rewritten from Thompson's dialect to gcc dialect <damo22>that might be a fun project, but for now im more interested in getting native drivers <homo>patch submitter said: In the future, since the Hurd runs translators (filesystem implementations) fully in userspace (somewhat like Plan 9 and FUSE, but on a deeper level), it could be possible to "undo" the 9p-over-Unix-sockets hack described in intro(4) and make file servers "real" Hurd translators. <damo22>ok so one of our developers did that <homo>there also was attempt to switch plan9 kernel to l4 microkernel, but I don't know what happenned with that project <homo>but going full-blown plan9 instead of plan9port is unlikely what you want, because it doesn't obey any standard, neither iso nor posix nor x11 nor anything else (even c99 is considered a bug), instead it provides replacements to all those standards <homo>anyway, 9p in combination with per-process network-transparent filesystem namespaces makes it absolutely irrelevant whether something is implemented by kernel, userspace, something outside of those or even everything of those at the same time, if you can flash firmware into camera, you can trivially implement 9p into that firmware and then from userspace mount it into /dev/camera, this way you don't have drivers neither in kernel nor in userspace, and camera doesn't <homo>have any operating system either <youpi>that's what mig rpcs are too <homo>somehow this idea migrated into virtio, even though it already was practical from the moment plan9 was created <homo>there's an experiment on beast of extremely difficult level - gpu namespaces for plan9 to provide simple, easy to use, network-transparent gpgpu <youpi>gpus are never easy to use efficiently, unless you just want to multiply matrices :) <homo>one of things I like about plan9's abstraction is that it makes ffi completely irrelevant, which is my main pain point with high-level languages, as I am trying to avoid ffi at all costs <homo>actually it's a pain point with any language other than c <homo>speaking of that, there is no need for much libraries either since programs work together, even cryptography like tls can be abstracted by separate file server and separate programs (tlsClient, tlsServer), so even with static linking you don't need to recompile much on updates <Gooberpatrol_66>idk if it was merged yet, i've never used it or seen it in the manual <Gooberpatrol_66>plan9's cpu arch independence is just an artifact of there being no RPCs and all IPC being through dumping data into virtual files <Gooberpatrol_66>idk if i like that, seems like much potential for corruption because of lack of type enforcement and parsing errors <Gooberpatrol_66>if you had a distributed os that did it "the hurd way" with mig rpcs i don't know what would be involved with making it architecture independent <damo22>seems like something hurd could already to <damo22>ERROR: cannot rcv packet, giving up <youpi>damo22: but will it support select() or such? <youpi>otherwise we won't have a way to block <youpi>again, the tcpdump source code will tell how they do it <damo22>its better to block not O_NONBLOCK <youpi>actually it'd be better to get packets from the "interrupt handler" <youpi>but it'll simpler for now to act as userland <damo22>youpi: i think the problem is, when you request the buffer size it returns 32768 and you have to read the whole buffer with bpf, and rump_sys_read() reads more than a whole packet at once.... how do i know how to split the data into packets? <youpi>that's odd, if that's ethernet frames, you don't have a proper way to do it <youpi>again, tcpdump code would tell <damo22>i cant know the size of the ethernet frame in advance of reading it, so i need to manage the buffer <damo22>i can read the maximum size reported by bpf, and then inspect the packet to know where to stop <youpi>but it's worse than that: ethernet doesn't tell you the size of the frame <youpi>you can't know where to stop <youpi>again, check how tcpdump does it <youpi>yes but that's way less important than having the monotonic clock <ZhaoM>ok I have a patch which updates that open issue page, I will send that patch after I confirm the patch can exactly clean the content about monotonic clock. <ZhaoM>`module` is the command, `/hurd/pci-arbiter.static` is the file <ZhaoM>is the rest of it parsed by Mach? <youpi>ZhaoM: mach does some interpretation (function calls such as task-create, variable expansion such as ${acpi-task=), see the mach manual <youpi>and the result is given to the module in argv[] <youpi>ZhaoM: ah, sorry there is no bootscript documentation there apparently <ZhaoM>I've found this page. We will need to add a module entry for storeio so I try to learn how to write a module entry <ZhaoM>but I don't think this page talking much about it <youpi>it was written before more modules were added, and nobody took the time to update it so far <youpi>but basically if you compare what is there and what you have in your box, you'll get the idea how it can be extended <ZhaoM>ok :/, so inference is needed <damo22>ff ff ff ff ff ff 52 54 00 12 34 56 08 00 rcvd a packet : [ OK ] 342 <damo22>00 00 00 00 00 00 00 00 00 00 00 00 00 00 /hurd/crash: /hurd/rumpnet.static <gnu_srs1>youpi: Do you still support hurd-recommended? Latest release was from 2017. That package has a dependency bug: depends on libsmbclient not libsmbclient0! <gnu_srs1>Causing problems (being removed) when upgrading samba libs. <youpi>ah, the recent samba stopped providing libsmbclient, so hurd-recommended just needs a binnmu, put on my list <gnu_srs1>How do you simulate being a console user when running qemu? Xorg.wrap has problems when configuring xverver-xorg-legacy. <youpi>you just need to make sure that the hurd console is started <gnu_srs1>Logging in in qemu graphic window gives TERM=hurd <youpi>nothing special concerning qemu about it <gnu_srs1>xorg.wrap is confused: /usr/lib/xorg/Xorg.wrap: Unable to detemine if running in a console. <youpi>did you dpkg-reconfigure xserver-xorg-legacy to allow all users, and not just console users? <youpi>as documented on the hurd-install page <gnu_srs1>I wasn to test if I can start X w/o suid root. <youpi>that can't work, Xorg still uses i/o access <gnu_srs1>seatd has three backends; native, elogind and systemd-logind.