No ARC/L2ARC?
Edit: of course not. This is actually just it’s just a ZFS user-facing ”front-end”, not a ZFS implementation.
Show HN: ZFS Implementation in Python
11–20 of 97 posts
Re: Show HN: ZFS Implementation in Python
#12What?! How?! Why?! This is the greatest thing ever. I wish I could just write code for the fun of it. Every time I wonder whether people will use it and give up before I even get started.
why not? writing code can fall into one of a few bucket. one of them is play.
Exactly! Write code that you find interesting and/or need for something and then share it. If someone uses your stuff, then great, if not, at least you've become a slightly better programmer! It's a win-win!
Re: Show HN: ZFS Implementation in Python
#13Re: Show HN: ZFS Implementation in Python
#14Pierre Menard, author of The Filesystem. But I'm surprised this is possible without a specification - how can you test a filesystem through hexdumps? The effects of some operations are going to pretty far-reaching, surely?
Might be interesting/useful to aim for zfs send/receive compatibility :)
And thanks for the Borges callout.
Re: Show HN: ZFS Implementation in Python
#15Note: this was implemented without referencing any ZFS source code and should not be subject to the CDDL.
Bad title. It’s not a ZFS implementation, so hold your horses.
Re: Show HN: ZFS Implementation in Python
#16Earlier quoted context omitted.
So we port this python to something not slow, and all the kernel-people can shut up about ZFS being terrible ;)
Dont forget, pypy is fast.
PyPy is faster than Python, yes. But Go, C and many other (compiled) languages are way faster than PyPy. Plus, if you use a language like Go or Rust then you avoid Python's GIL and you'll have much more reasonable memory usage. Best of all, deploying is a matter of copying a binary, rather than having to deal with the absolute disaster that is Python packaging.
Re: Show HN: ZFS Implementation in Python
#17Hey alcari!
I know you from ICV - we used to hang out online on the forums and IRC.
Nice work on this project, I'm looking forward to diving into the codebase!
Re: Show HN: ZFS Implementation in Python
#18Earlier quoted context omitted.
Would the CDDL matter for a python implementation that will never become part of the kernel?
You'd want a reverse-engineering lawyer, so be certain. But my (IANAL) guess is: If this is a proper reverse-engineered implementation, you could then convert _this_ implementation to C, and contribute _that_ into the kernel. Except, it seems this is BSD-licensed, so I'm not sure how that would work in the kernel (which is GPLv2).
BSD is a subset of GPL's restrictions, so you can include BSD-licensed code in a GPL work.
Re: Show HN: ZFS Implementation in Python
#19Earlier quoted context omitted.
Would the CDDL matter for a python implementation that will never become part of the kernel?
You'd want a reverse-engineering lawyer, so be certain. But my (IANAL) guess is: If this is a proper reverse-engineered implementation, you could then convert _this_ implementation to C, and contribute _that_ into the kernel. Except, it seems this is BSD-licensed, so I'm not sure how that would work in the kernel (which is GPLv2).
BSDL code is fine in the GPLv2 kernel. E.g., most of the DRM drivers are dual BSD-GPL licensed.
Re: Show HN: ZFS Implementation in Python
#20Earlier quoted context omitted.
You'd want a reverse-engineering lawyer, so be certain. But my (IANAL) guess is: If this is a proper reverse-engineered implementation, you could then convert _this_ implementation to C, and contribute _that_ into the kernel. Except, it seems this is BSD-licensed, so I'm not sure how that would work in the kernel (which is GPLv2).
BSD is a subset of GPL's restrictions, so you can include BSD-licensed code in a GPL work.
Subset isn't quite accurate, but "GPL compatible" might be a good way to describe it.