Writing a FUSE file system in Go
bazil.org
bazil.org
BTW does anyone know if there is something similar to FUSE, but for block-devices? I've written a rudimentary NBD server to read my old OS X sparsebundles on Linux, but NBD seems a bit over-general for that purpose.
https://github.com/acozzette/BUSE
The disclaimer says it's experimental, though.
Why would you design something like that? At least give people instructions.
/edit: https://groups.google.com/d/msg/golang-nuts/X9z59NxSvtg/Sj0C...
The assumption is that if you use this software you'll read the instructions and know how to use it. In other words, being able to put it online was an afterthought. Not that this isn't a fixable problem.
TL;DR: historical reasons, designed for different usecase, can be fixed.
Some time ago, I wrote a movie database with fuse backend and data supplied by imdb. It is really easy and straight forward to program.
Plus, whatever you did, there's the small matter of Linux people accepting you changes. A Linux fork is useless; if it's not in mainline, it doesn't exist. Historically the Linux folks haven't been very happy with these kind of changes...
But I wasn't talking about that stuff specifically (which might or might not be incompatible with core Linux). Parent lamented of Linux generally not trying out new research ideas. Well, why doesn't he have a go at it?
Everyone needs to be a kernel developer, a XWindows developer, a GNOME developer, a KDE developer, ... or just shut up.
And even when something is done that goes out of the usual copying existing ideas, there is the uphill battle to get it eventually integrated and accepted, if ever.
I have been coding before Linus could even think about doing Linux, and have better things to do with my free time.
I use OS X. Could not care less about Linux except on a server. Have started with Sun OS and HPUX back in the day.
>Everyone needs to be a kernel developer, a XWindows developer, a GNOME developer, a KDE developer, ... or just shut up.
Pretty much sums it.
>And even when something is done that goes out of the usual copying existing ideas, there is the uphill battle to get it eventually integrated and accepted, if ever.
And why would it be "integrated and accepted" if the people don't like it? Because it's "novel" and "out of the usual"? I'd say, "we actually want it in our kernel" is a far more compelling argument than "It's novel".
>I have been coding before Linus could even think about doing Linux, and have better things to do with my free time.
So, you "have better things to do with my free time" but the people doing Linux kernel work should implement novel things for your amusement? How exactly do you justify that?
(As for "coding before Linus could even think about doing Linux", should we be impressed by the timespan alone? Tons of dabblers and mediocrities have also done that).
Why should it be for my amusement?! I was only stating a fact.
> (As for "coding before Linus could even think about doing Linux", should we be impressed by the timespan alone? Tons of dabblers and mediocrities have also done that).
No, it just means I use GNU/Linux like any other OS and I don't care about OS religious wars.
The clone(2) system call is somewhat superficially similar to Plan 9's rfork(2). Linux came to the same conclusion as Plan 9; threads vs. processes is a false dichotomy. The fundamental schedulable kernel entity is a thread and threads may or may not not share resources, like address space. The similarities end quickly, however. Linux clone(2) is crippled by the fact that flags that allow novel abstractions, like universal network transparency, such as the flags that set up per process namespace are restricted to the superuser. This is of course a consequence of the Unix security model and because Linux has suid binaries.
FreeBSD has had some work porting FUSE. I'm not sure the status I just remember seeing it as a GSoC project.
Some people are working on FUSE for OpenBSD. The GPL license of libfuse seems to be a problem but the kernel side stuff is implemented: http://comments.gmane.org/gmane.os.openbsd.tech/31704
Hopefully they've since addressed the user mounting issue. I've not used it recently to check.
$ ls -l `which fusermount`
-rwsr-xr-x 1 root root 31384 May 31 04:38 /usr/bin/fusermount
Quick UI feedback, I had to use the keyboard to get to the next slide, it seems not possible with purely the mouse. Might want to change that.
Chrome 27.0.1453.110, Ubuntu.
It does work - but fairly non-obvious.
It's a pity the presentation isn't more responsive / dynamic to the browser's viewable area, but at least the content is there and at least this is an interesting topic which is worth my time scrolling through the slides - which is the most important thing :)