IRC channel logs

<youpi>about BSD: the problem is the BSD macro itself, that doesn't actually say what it means precisely to be defined. _POSIX_SOURCE does have a numbering principle that allows to know, BSD does not

<youpi>it's no different from trying to compile a "recent" BSD-aware application on an old BSD system

<youpi>the macro being defined doesn't mean all very recent interfaces are available

<youpi>also, what about the divergences between openbsd, netbsd, freebsd

<youpi>so, in the end, yes, the Hurd essentially exposes a BSD interface

<solid_black>hi youpi!

<youpi>by very definition, it cannot expose all BSD interfaces, since as soon as some BSD introduces a new interface, well the Hurd won't magically have it as well

<youpi>but again, that's no different from existing old BSD systems

<youpi>so, no, application usually shouldn't rely on #ifdef BSD, that'll be mostly unsuccessful, and not just on the Hurd

<rsmarples>youpi: i would expect BSD4 inlcudes t be present

<rsmarples>such as netinet/in_var.h

<rsmarples>or net/route to define the BSD routing mechanism

<rsmarples>Linux does not define BSD, neither does macOS which is much more of a BSD than hurd

<youpi>in_var: what for? the versions in netbsd/openbsd/freebsd seem quite diverse, for instance

<youpi>net/route would be useful indeed, contribution welcome

<youpi>linux is really not a bsd-ish system, its macros don't follow the bsd numbering

<youpi>macos does not want to look like bsd, even if it uses it

<rsmarples>I load in_var.h to see if a BSD as implemented IN_IFF_TENTATIVE

<youpi>that macro is only defined in netbsd and not in freebsd and openbsd for instance

<rsmarples>currently yes

<youpi>(at least the versions I have on my disk)

<youpi>"currently", that is the point

<youpi>so #ifdef BSD is pointless

<rsmarples>so we agree it's pointless, glibc on hurd shouldn't define it as it's so pointless :)

<youpi>there are some uses that make more sense, as in interfaces that are there for 30 years

<rsmarples>such as?

<youpi>the question is how much benefit you get from defining it vs how much problems you get

<youpi>afaik, it's more beneficial

<rsmarples>beneficial but in your view yet pointless

<youpi>such as sin_len and such

<youpi>I don't rember everything by heart

<youpi>now, if the balance changes, sure we can change

<youpi>but then there will be issues popping up

<youpi>that will need to be dealt with

<youpi>don't ask me to take that charge

<rsmarples>where do i find struct sockaddr_dl?

<youpi>we don't have dl (yet, contribution welcome)

<rsmarples>and yet AF_LINK is defined which implies it's natural existance

<rsmarples>ACTION sighs

<youpi>actually in debian we commented the definition

<youpi>the definition doesn't come from the hurd header

<youpi>it comes from a common header

<youpi>ah, no, a hurd-specific header got added

<rsmarples>well im on Gentoo as it's hurd image actually works for me

<rsmarples>git fails to unpack, but i can always ssh the source around for that

<youpi>I'll comment these AF_*, they should indeed not be defined

<rsmarples>youpi: can you #undefine SIOCAIFADDR as well please as if_aliasreq isn't defined either

<Pellescours>I tried to boot hurd with all cpus available to the system (pin patch reverted). And on fs intense period the fs get kinda corrupted (I don't remember the exact messages)

<rsmarples>grr, libpcap with hurd isn't in portage and the 9999 ebuild needs git which doesn't worn

<rsmarples>sigh

<rsmarples>is hurd networking generally slow? rsync is taking an age

<solid_black>I would really love to back "for real" :|

<gnucode>hello friends!

<gnucode>I'm compiling netsurf from source again.

<Alicia>good luck!

<gnucode>thanks. I'm also installing surf, so that one always works apparently.

<gnucode>hmm, the surf browser works ok too.

<Gooberpatrol66>solid_black hello!

<gnucode>I'm not sure how to tweak the url once surf is open.

<gnucode>ahhh, C-g

<gnucode>I'm not sure if surf has tabs...

<gnucode>compiled.

<gnucode>Just 4 spots where you have to define PATH_MAX...not ideal, but I'm not sure how to properly make the change yet...

<gnucode>and it looks like I need to update the Hurd's time...

<gnucode>I'll have to check the debian wiki for how to do that again.

<gnucode>rsmarples: in my humble opinion, the hurd networking is particulaly slow on real hardware.

<gnucode>I am running the Hurd on a T420 using rump for ethernet. I'm getting 10 - 100 Kb/s. :(

<gnucode>Running it in a vm has much faster ethernet.

<gnucode>and maybe just the rump ethernet driver has some issues...really not sure. Damien know more about the current rump driver situation. I'm glad that he wrote it, so that this laptop has working ethernet.

IRC channel logs

2026-05-26.log