IRC channel logs

<AlmuHS>damo22: how did you got to login using smp gnumach? My VM always freeze just before ask the user

<gnucode>damo22: I did the same thing earlier! haha

<AlmuHS>i think that commands must be written with /

<AlmuHS>damo22: now that smp booting is more advanced, the next that we have to check is the race conditions

<AlmuHS>now i go to sleep. in the morning i chat again if i get time

<gnucode>So it looks like I will be chatting with Kent Overstreet this Friday (author of bcachefs) to talk about cool filesystem stuff. And weather bcachefs can be used on the Hurd.

<gnucode>Is anyone interested in joining that conversation?

<gnucode>the email chain is in bug-hurd@gnu.org

<Gooberpatrol66>gnucode: i probably wouldn't have anything to add to the conversation, but i would listen in because it sounds interesting

<gnucode>Gooberpatrol66: I definitely don't have anything to add to that conversation either. :) But it sure sounds like it would be worth something. Maybe reply to the email thread, and I'll let you know about it.

<gnucode>Looks like it'll be this coming Friday morning EST.

<solid_black>hello!

<damo22>hi solid_black

<solid_black>hi damo22!

<solid_black>so I am concerned about the call that gnucode is setting up with Linux developers, Kent Overstreet in particular

<damo22>(03:29:14) skeletonlamb [~a@c-71-229-198-151.hsd1.co.comcast.net] entered the room.

<damo22>do we have a pretend rms ?

<solid_black>I don't know of a nice way to say this, but basically I don't think any of us here is enough of an expert in fs development, and this will only end in great disappointment

<solid_black>there is a chance that it won't be a complete diaster if youpi participates though

<damo22>i think its just an opportunity for Kent to explain some basics of what he made

<solid_black>I'd love to participate too, but then again, who am I? it's not like I know much about fuse or bcachefs internals, or fs dev, or anything

<damo22>solid_black: dont think of personal interviews as a programmer, you will only think of the worst case scenario :D

<solid_black>it's surely not a job interview :) but Kent is a serious big-time Linux developer, and compared to him, we're just a bunch of amateurs (no offense), and considering how bad of an impression Linux developers already have of the Hurd, it's really concerning what sort of an imression this is going to make on him

<damo22>thats a slightly disappointing view of us

<damo22>i dont put Linux developers on a pedestal

<damo22>even linus

<solid_black>really don't mean to offend anyone, and maybe this is the impostor syndrome in me speaking

<solid_black>maybe I'm wrong though, do you know much about fuse? or file systems?

<damo22>no i dont know much about filesystems

<azert>Hello all, I will not be able to join since im Anonymous, and in a work meeting at that time. But please solid_black participate: at worst it will be a funny talk for Kent and nothing will come out of it

<azert>Of course if you wish, I’m just saying not to be afraid

<azert>The probability of anything coming out of it is very small, but there is nothing to lose. I wasn’t expecting his answer!

<solid_black>I was expecting him to ignore the mail too

<damo22>what is bcachefs?

<solid_black>see? :D

<azert>I agree that someone intimate in the Mach pager api, libdiskfs and fuse would be great at that meeting

<solid_black>I do kind of understand Mach VM / paging, I must say

<solid_black>from the looks of it, I even understand it best among those who have looked at it recently

<solid_black>and I mostly understand libdiskfs

<damo22>so go to the meeting

<damo22>if you want

<azert>So please participate!

<solid_black>but you realize he's like what? one of the top 3 fs devs in the world? (I'm thinking Al Viro, Davide Chinner, and him)

<damo22>sounds good

<solid_black>we're jumping way above our heads

<azert>Then it’s a great occasion

<solid_black>but yeah, I'd like to go to the meeting

<solid_black>it's too late to back out of it anyway

<azert>I agree with damo22, if you see this as a job interview you are probably not going to get ot

<azert>Try to act like his peer ;)

<azert>It’s free software, in the eand

<damo22>what is fuse? do we even need it for hurd?

<damo22>file systems in userspace

<solid_black>FUSE is "filesystem in user space", it's both the name for the concept, and the name of Linux's specific mechanism, of offloading fs to userland

<damo22>yeah, i think it may be unneeded for filesystem on hurd

<solid_black>it's basically a giant hack that pretends to be a fileystem implementation to the rest of the kernel, and then sends requests and receives responses from a userland program that _actually_ implements the fs

<solid_black>on the Hurd, *of course* filesystems are implemented in userland, that's the only and the natural way everything works

<solid_black>but that's where the similarities end

<solid_black>you cannot just take a linux fuse fs, using libfuse, and run it on the Hurd

<solid_black>there has been a project make a library that would have the same API as libfuse, but act as a Hurd translator, specifically to facilitate porting linux filesystems

<damo22>i imagine fuse has an api

<solid_black>last I heard, it was never completed, but who knows

<solid_black>it has a kernel<->userland protocol and a userspace library (libfuse) for implementing that protocol, yes

<damo22>solid_black: you seem to know more about fuse than you admitted

<solid_black> https://www.gnu.org/software/hurd/hurd/libfuse.html

<solid_black>I know the basics, around as much as I have just told you

<azert>I think that gnucode idea was that this would be the easiest to port bcachefs to the Hurd, but I doubt it would be the best

<solid_black>I have also hacked on a C++ fuse fs (darling-dmg), though I don't think I interacted with the fuse parts of it much

<azert>Or even the easier

<solid_black>yeah, I don't think it'd be the best or the easiest one either

<damo22>if someone implemented libfuse api and made it as a hurd translator, surely it would work natively?

<damo22><braunr> zacts: the main problem seems to be the interactions between the fuse file system and virtual memory (including caching) <braunr> something the hurd doesn't excel at <braunr> it *may* be possible to find existing userspace implementations that don't use the system cache (e.g. implement their own)

<azert>Yes, that’s a possibility that needs to be kept open for discussion

<nikolar>Sounds interesting

<solid_black>youpi: ping

<youpi>pong

<solid_black>hello!

<solid_black>any thoughts on the above discussion? are you going to participate in the call that's being set up?

<youpi>I don't have time for it

<youpi>(AFAIK the fuse hurd implementation does work to some extent)

<solid_black>I should at least try out Hurd's fuse before the call, good idea

<solid_black>maybe read up on the Linux's fuse

<solid_black>thoughts on using fuse vs libdiskfs for bcachefs?

<youpi>using fuse would probably be less work

<youpi>and it'd probably mean fixing things in libfuse, which can benefit many other FS anyway

<solid_black>is it true that the "low level" API of libfuse is unimplemented and unimplementable?

<youpi>I don't know what that "low level" API is

<solid_black>this IIUC https://github.com/libfuse/libfuse/blob/master/include/fuse_lowlevel.h

<solid_black>> libfuse offers two APIs: a "high-level", synchronous API, and a "low-level" asynchronous API. In both cases, incoming requests from the kernel are passed to the main program using callbacks. When using the high-level API, the callbacks may work with file names and paths instead of inodes, and processing of a request finishes when the callback function returns. When using the low-level API, the callbacks must work with inodes and responses must be se

<solid_black>nt explicitly using a separate set of API functions.

<youpi>where did you read that it'd be unimplementable ?

<solid_black> https://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/README?h=libfuse/master

<solid_black>> This is simply because it is to specific to the Linux kernel and (besides that) it is not farly used now.

<youpi>In case the latter should change in the future, we might want to re-think about that issue though.

<solid_black>so, sounds like it's perhaps implementable in theory, but that'd require additional work and design

<youpi>see the sentence below...

<solid_black>the low-level API is what bcachefs uses

<youpi>well, additional work and design, of course

<solid_black>seems to, at least, from a quick glance

<youpi>any async API needs some

<youpi>but I don't see why it would not be possible

<youpi>mig precisely supports asynchronous stubs

<solid_black>bcachefs-tools/cmd_fusermount.c is just 1274 lines, which inspires some hope

<solid_black>asynchrony is not the problem, I imagine (but I haven't looked), but being too tied to Linux might be

<youpi>it's not really tied, as in it doesn't seem to use linux-specific functions

<youpi>but it uses linux-like notions, which indeed need to be translated to the hurdish notions

<youpi>but that's not something really tough

<youpi>just needs to be worked on

<solid_black>can/should I mention in the email that you won't be able to make it?

<youpi>you can yes

<solid_black>what has Joshua gotten us into... :) let's hope it doesn't go too bad

<Gooberpatrol66>if the discussion were about the internals of bcachefs, it would probably go over our heads, but it's mostly going to be about porting the fs using the tools that already exist, so less impostor syndrome i think

<Gooberpatrol66>still i recommend studying for the meeting

<Gooberpatrol66>i'm trying to build hurd's libfuse and bcachefs-tools

<Gooberpatrol66>internet comments say bcachefs's fuse support has been broken for a while, we'll see if that's still the case

<Gooberpatrol66>what are the obstacles to using something with libfuse as hurd's rootfs?

<youpi>it'll need adding startup support to libnetfs

<youpi>that'd be needed for nfs etc. as root FS anyway

<solid_black>fwiw, in my proposed boot scheme individual translators don't have to do anything special to be the rootfs

<solid_black>(which is one of the major goal of the design)

<gnucode>solid_black: I'm pretty excited too. :)

<solid_black>hi gnucode!

<solid_black>thanks for recording those two last videos of the terrible mdns responder :)

<solid_black>but, uhhh, what have you gotten us into with the call

<gnucode>I am trying to think that my goal here is to help Kent. He apparently could use some funding to get bcachefs merged into linux. If we use this recorded discussion as a plug to his patreon, then it might help him out.

<gnucode>hahahaha. :)

<gnucode> "move before you are ready".

<gnucode>solid_black: even, if all we get out of this conference call, is an interesting discussion...and potentially a new friend...

<gnucode>it'll be time well spent.

<solid_black>it'd certainly be interesting

<gnucode>solid_black: I also thought he was going to ignore my email too. :)

<solid_black>_will_ be interesting rather

<gnucode>I think I will email one of two of the guix developers to see if they want to chime in...since they might be interested in hurdy stuff too.

<gnucode>ya'll ok with that?

<Gooberpatrol66>ping janneke, he's probably the guix guy that knows most about hurd

<gnucode>janneke: https://lists.gnu.org/archive/html/bug-hurd/2023-09/msg00022.html

<gnucode>let me know if you want to join in.

<solid_black>I suppose Ludo also knows quite a bit about Hurd, and filesystems in particular (I saw that he wrote several of the translators)

<gnucode>then I will definitely email him!

<gnucode>also, whose the college student that was thinking about making a new filesystem for the Hurd.

<gnucode>does he want in on this call?

<Gooberpatrol66>nikolar

<nikolar>Yes, I'm here

<nikolar>When would this call thing be

<gnucode>I am going to email kind soon and suggets 11am EST.

<gnucode>Kent*

<gnucode>solid_black: and I will probably meet an hour before just to test that the conferencing works.

<Gooberpatrol66>are we recording it?

<nikolar>Uh sure why not

<nikolar>I can probably make it

<gnucode>if Kent is ok with recording it, then sure.

<nikolar>gnucode: how is this going to organized

<nikolar>Something like jitsy?

<gnucode>probably https://bbb.sfconservancy.org/b/

<gnucode>big blue button.

<gnucode>or maybe you have a jitsi account we can use.

<nikolar>I don't unfortunately

<nikolar>But bbb is apparently also open source so no issues there

<gnucode`>whoopsie daisy...I forgot to log off my other irc account at home.

<janneke>gnucode: thanks, I'll keep lurking; a journaling filesystem would be great although i'm not a fan of rust

<Gooberpatrol66>bcachefs is written in c (for now)

<janneke>ah good

<janneke>and how come bcachefs and not ext3, ext4, eg?

<Gooberpatrol66>i mean, personally, i'd want something with snapshots, bitrot protection, caching, RAID, etc

<Gooberpatrol66>if hurd gets this fs + smp + 64-bit, i would actually be able to contemplate putting it on my server

<Gooberpatrol66>but those others should work too if libfuse gets working

<janneke>ACTION doesn't really need all that and would gladly trade it for less, and simpler code

<gnucode`>janneke: what sort of simplier code fs design would you like?

<gnucode`>Gooberpatrol66: what do you use your server for?

<gnucode`>janneke: I'm just looking forward to meeting people that are much smarter than I am.

<Gooberpatrol66>NAS, git forge, password sync, VM storage, personal wiki, torrents, package server, nextcloud (but that's broken right now)

<gnucode`>Gooberpatrol66: I would like to use nextcloud too. I was for a while, but docker makes me think really really hard...

IRC channel logs

2023-09-26.log