IRC channel logs
2026-04-09.log
back to list of logs
<damo22>it supports SATA so mSATA is the same thing <Arsen>I thought it depends heavily on Linux namespaces <gnucode>also what's cool about Guix (I don't know if you know this). <gnucode>but there is Guix System and Guix. Do you know the difference between those ? <gnucode>and I don't know how either? magit hand waving ? <gnucode>ok. Just checking. I don't know of anyone running Debian Hurd + Guix. <bjc>guix doesn't require linux namespaces for most things <Arsen>but what I was referring to is, to run builds, nix and guix both set up very controlled environments using namespaces, which is very Linux specific <gnucode>Arsen: you are absolutely correct. The Hurd does not have those features. :) <bjc>the guix builders aren't isolated on hurd <gnucode>I don't know how hurd guix makes isolated build environments on the Hurd. I believe that is still something that they are trying to work toward. <Arsen>yes that answers my questions ;) <bjc>there's an old patch to use hurd servers to do isolation, but it's rotted a bit <etno>I think that the eth multiplexer matches the idea of the bridge translator <gnucode>etno: thanks for letting me know that the bridge translator on the wishlist page is essentially the eth-multiplexor. I'll delete the bridge translator in my next wiki updates. <sneek>Welcome back gnucode, you have 1 message! <sneek>gnucode, janneke says: as debian gnu/hurd has many packages available, i would hope building it from source from a git checkout, should be doable <etno>Talking about virtual bridges, I wonder if the multiplexer can do VLAN tagging. That wouldn't be hard to implement. Maybe it does.... <etno>Eth-multiplexer doesn't seem to do that. And it wouldn't be as easy as I said, because the virtual interfaces are created implicitly. <youpi>the name could include the tag number? <etno>There would need to be some naming to pre-configure interfaces for use on a VLAN <etno>If there is a name given to the virtual interfaces, I suppose that it would work, yes <etno>A bit like ifupdown does <gnucode>etno: I've read the intro to that wiki article you just gave, but I'm still lost. what's the point of VLAN tagging ? I'm guessing it helps route internet traffic... <youpi>it helps isolating ethernet lans <youpi>instead of isolating by using different switches <youpi>you virtually split your switch with vlans <gnucode>so making your nework more secure. kk. <etno>Also, gnucode , about the earlier topic of the bridge translator, I realize now there's an essential difference with eth-multiplexer <rrq>I think linux networking uses an ".N" affix on interface name for vlan tagged traffic paths <gnucode>etno: so I shouldn't delete the bridge translator from the wiki...just link to the eth-multiplexor ? <etno>eth-multiplexer connects several network stacks to one physical interface; while in the example given for the bridge translator, it connects several physical interfaces. <etno>So the bridge translator is meant to create a software Ethernet bridge (or probably a switch) on a machine with several cards <youpi>possibly vde could be just reused <youpi>the hurd, or how not to maintain software yourself <etno>Haha, I'll keep that one for my hurd show in may ! <etno>So, gnucode, as an example of what VLANs can achieve : with 2 machines having only one single Ethernet adapter each, you could connect subhurbs of both sides together in an isolated network. <etno>While the other applications on the nodes could still use the adapters as usual <etno>Don't know if this is any useful, but heh <gnucode>etno, I'm going to try to reword what you just said to make sure that I follow. <gnucode>If you and I met decided to throw a hurd party, and we both brought our laptops running the Hurd...We could use eth-multiplexor (once it supported VLAN tagging), to allow our subhurds running on different laptops to talk to each other...And to those subhurds...they might think they were both using the same GNU Mach kernel ? <etno>Not the same kernel, but they would be on a LAN on their own <gnucode>why would we want to do that? What coolness would that enable us to do ? <gnucode>I suppose that it would let us use telnet securely ? <etno>The usefulness lays in the possibility to run isolated networks using only one physical network. There's not much need for that during a Hurd party <gnucode>etno: suppose that I want to create isolated networks via VLAN tagging...do I need access to the router to do that ? <gnucode>so, I'm brainstorming here...with VLAN tagging, you could create "network A", "network B", "network C"...and A would be a network that tunnels your requsets on a VPN, and B would using a pi-hole to block adds, and C would tunnel your internet requests through TOR. With VLAN tagging you could have all 3 networks, with one physical network. And users could switch to each various networking capability at whim ? <gnucode>Even better, they could potentially set up their translators...to tell certain programs to use the VPN, and other programs to use the tor network. <gnucode>does VLAN tagging let you create subnetworks that work via wifi as well ? <etno>I think that what you are describing is in fact using multiple network stacks, which is typically one feature of subhurds <etno>With VLANs, you could "share" those networks between several physical computers, while using only one Ethernet adapter on each. <gnucode>hmmm. networking is something I really don't quite grasp as well. There's soo much to learn. <jab>well my hurd just locked up. <jab>I was running an update on another tab. <jab>and the system is froze now. <jab>It's actually kind of interesting. I can still see my Emacs instance, and as I'm typing now, I see the messages appear on the Hurd. <jab>But when I move the mouse on the Hurd...naha. <jab>and I don't have the simple mdns responder set up... <jab>so I can't actually do anything to the Hurd but hard shut it off. I'll give it maybe 1-2 hours, and then hard shut it off. <jab>maybe that'll give the update time to finish. <jab>oh, I might add Fil-C somewhere to the Hurd wiki. Apparently it lets you compile C code and make it memory safe. The downside is that it makes the binary run slower... <jab>but it maybe would help us catch some memory bugs. <jab>diegonc: it's nice when someone else fixes something for you. :) <jab>diegonc: wanna try porting openmdns to the Hurd ? <jab>and/or fixing the terrible-mdns-responder ? <diegonc>jab: what's the package name? openmdns doesn't seem to appear in thre debian datasbase <jab>it's OpenBSD's mdns provider. It's not in base, but it's the main one the users seem to recommend. <jab>it might not be packaged by Debian, and it might not be very portable. <sam_>does it even work on linux? :p <sam_>(to answer your q from yesterday by the way: no, not tried guix (on hurd or otherwise), maybe at some point, but enough to do for now) <jab>sam_: actually it might not work on Linux... <sam_>not sure how surprised i am though, i looked at avahi a while ago and didn't love it but it wasn't in detail <jab>openmdns targets OpenBSD specifically. <sam_>the problem is that the openbsd stuff can often be pretty hardcoded <diegonc>intresting, but looks hard to port if it is a niche openbsd app <jab>sam_: well, it depends on which openBSD software... openssh is pretty portable. :) openhttpd, opensmtpd, pf (was ported to all the *BSDs). There's probably other examples. <sam_>openssh is not, openssh has a separate port project which some of its developers maintain <jab>diegonc: yeah that was my mistake. I assumed it was portable. <jab>sam_: what's the practical difference ? Openssh (or a version of it) runs on every major OS. I grant you that they maintain "portable versions" of their software... <sam_>the practical difference is that the software doesn't tend to be portable by itself, and the upstream variants usually don't support non-openbsd, which means that unless someone has actively done it for openmdns, it probably won't work on linux <jab>oh, I forgot GOT. That also has been ported to Linux. <sam_>i.e. just git cloning it or whatever has a high chance of not working with basic issues <jab>sam_: we are in complete agreement. openmdnsd is not portable. What are we disagree about ? <sam_>nothing, I was just saying that: [18:56] <sam_> the problem is that the openbsd stuff can often be pretty hardcoded <jab>What are we disagreeing about ? <jab>I do have a little project maybe I should try to fix. <jab>i3status doesn't really work so well on the Hurd. <jab>it doesn't display the ip4 or ip6 ethernets, can't read load, or know the battery. <diegonc>sam_ re. clearly hardcodes openbsdisms already :: I think for openNTPd the debian maintainers added an autotools based build system on top of the upstream souce <sam_>we have it packaged as well i think but sadly it seems to trail behind upstream a lot, at least the copy we use (maybe there are others) <sam_>but there are newer commits, so maybe they just forgot to push the tag <sam_>i've started looking a bit at chrony instead for hurd <jab>well this is super annoying. my Hurd box locked up again just now, and I cannot ssh int oit. <jab>ssh is just sitting there. So looks like I'll have to hard kill the Hurd again. <jab>man I hate doing that. <jab>the hurd journal can't get merged soon enough. <jab>so, I had to manually run e2fsck on the T420. What's slightly annoying about that, is that I use the dvorak keyboard layout. So I had to type it in qwerty, but the keys were in the wrong place. <jab>And for some reason the console did not display the characters as I typed them. <jab>and I rebooted...and now my keyboard is not working... <jab>does ext2 support backups ? <jab>and I can't ssh into the laptop. so I'm going to have to kill the machine again.