Writing a FUSE file system in Go(bazil.org)
bazil.org
Writing a FUSE file system in Go
http://bazil.org/talks/2013-06-10-la-gophers/#1
9 comments
FUSE is somewhere on the top of my "cool tools I wish I had a use for some day", together with Go, so thanks for posting this!
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.
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.
The Camlistore VFS is written in Go and has read-only fuse bindings if you want to have a look: http://camlistore.org/code/?p=camlistore.git;a=tree;f=cmd/ca...
> BTW does anyone know if there is something similar to FUSE, but for block-devices?
https://github.com/acozzette/BUSE
The disclaimer says it's experimental, though.
https://github.com/acozzette/BUSE
The disclaimer says it's experimental, though.
Thanks. I see it wraps NBD, too.
The content of the slides is good/informative.. but the UI for the slides is terrible. I didn't know where to click, I tried clicking on the slide next to it... tried dragging the slide over, and selected a bunch of text. Clicked a few other parts of the screen.. Then it occurred to me to try the arrows. If I hadn't thought of that, I would have just left.
Why would you design something like that? At least give people instructions.
Why would you design something like that? At least give people instructions.
I'm pretty sure you can't drag slides over in Powerpoint either. It's a tool for the presenter, the guy giving the talk, not for you, guy on the Internet. It's HTML 5, so it's easy to share with you or with the audience, but he is the user of the tool, not you.
/edit: https://groups.google.com/d/msg/golang-nuts/X9z59NxSvtg/Sj0C...
/edit: https://groups.google.com/d/msg/golang-nuts/X9z59NxSvtg/Sj0C...
You make a valid point about usability from the point of view of viewing the slides online. However, it wasn't designed for that, but as a tool by the Go authors to be able to quickly churn out presentations in a simple markup language and run code from within the presentation similar to how play.golang.org works. There's a presentation on that, actually[1]
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.
[1] http://talks.golang.org/2012/go-docs.slide#20
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.
[1] http://talks.golang.org/2012/go-docs.slide#20
As a NoScript user, I sometimes try to explain to people that for every site ruined by NoScript, there's another site that's made easier to use. This would be one of the examples of the latter. I just got a nice HTML text-ish file with headers for the slides.
Clicking on the next slide works fine for me, and it was the first thing I tried.
You have to click on the left third of the next slide, or the right third of the current slide.
It's also basically impossible to read on an iOS device.
It seems to me with Linux's dominance, FUSE is becoming an attractive way to export APIs, since by operating at the filesystem layer full access is guaranteed to all programs regardless of creed... without having to write a C library, or a corresponding library for every language. This is particularly useful for shell scripts. It's still a tradeoff though, and *BSD'ers won't be super pleased if it becomes too popular.
Linux discovering Plan 9 ideas, only 20 years later.
Linux is mostly about re-implementing old stuff, sadly I am yet to see many new ideas being explored, besides what commercial UNIXes and Mainframes offer.
It's open source, you can go and implement this "novel stuff" yourself.
No, you really can't. Plan 9 wasn't a modification of the Research Unix they used at the Labs, it was a new operating system because Unix couldn't implement the required abstractions in an orthogonal way. Plan 9 replaces the abstractions offered by Unix with different new ones; you can't just add new abstractions on top of old ones. It's a completely different world, different process and security models which are incompatible with the old models. Linux wouldn't be Linux anymore. One reason why you would want Linux with Plan 9 semantics instead of Plan 9 is because Linux has a lot of drivers. Unfortunately, the I/O model is a consequence on how Plan 9 does things, and if you want Plan 9 semantics in Linux you'd have to modify all the drivers. Every driver that uses IOCTLs would have to be modified, which is pretty much every one of them.
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...
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...
Linux has been implementing Plan 9 features piecemeal for ages. For example: /proc fs, several system calls, utf-8, etc.
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?
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?
The Linux procfs is nothing like Plan 9's /proc or Inferno's /prog, in fact it's nothing like any other operating system's procfs. All procfs are different, only the name, and perhaps the mountpoints are similar. I'm not even talking about implementation details, I'm talking about the abstraction itself; what does it do and what it allows you to do.
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.
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.
It is funny how the typical Linux zealots answer is go and implement the stuff one complains about.
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.
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.
>It is funny how the typical Linux zealots answer is go and implement the stuff one complains about.
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).
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).
> 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?
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.
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.
It was really closer to 10 years later. FUSE has been around for quite a while.
And the ideas that eventually turned into Plan 9 namespaces first appeared in 8th edition Research Unix, for which the manual came in 1985.
NetBSD has a userspace filesystem api with a FUSE compatibility layer: http://www.netbsd.org/docs/puffs/
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
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
A couple of years ago I used to use sshfs quite extensively in FreeBSD and that worked fine. The only problem was the FUSE required root permissions to mount (unlike Linux). But aside that, it worked fine.
Hopefully they've since addressed the user mounting issue. I've not used it recently to check.
Hopefully they've since addressed the user mounting issue. I've not used it recently to check.
Yeah it is quite cool.
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.
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.
The Wikipedia page has a list of interesting projects based on FUSE: http://en.wikipedia.org/wiki/Filesystem_in_Userspace#Example...
Very informative for slides. I'm used to worse.
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.
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.
That's a sizing problem. I couldn't work out how to switch slides until I'd maximized my browser, allowing the neighboring slides to sneak into view (and thus visible to click).
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 :)
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 :)
Move the mouse pointer until it becomes a hand at the left of the next slide (but not too far).
It does work - but fairly non-obvious.
It does work - but fairly non-obvious.
Clicking the next slide goes to the next slide fine for me.
Chrome 27.0.1453.110, Ubuntu.
Chrome 27.0.1453.110, Ubuntu.
Somebody should port GlusterFS to Go!
oh, wow - I always thought FUSE was a c-library - didn't realize it was this "smart". I guess I'll have to go look more closely at the various FUSE projects :-)
[deleted](1)
[1] https://github.com/justincormack/ljsyscall