<joepie91>
jD91mZM2: so, some random examples, 1) code editor implementations that separate code concerns and display concerns, and can transparently reformat code to the preference of the reader without modifying the underlying code (bidirectionally), 2) a unified syntax specification system that can be used to derive (correct!) syntax highlighters for many editors from a canonical language spec, 3) memory-safe equivalents of lots of memory-unsafe things,
<joepie91>
of course, 4) non-commercial hosting/service infrastructure, 5) better (ideally federated) project management systems that are a) not github and b) not 'insular' like github where every repo/org is its own little island
<joepie91>
6) unified messaging implementation that isn't a trainwreck like libpurple
<joepie91>
etc. etc.
<joepie91>
and that's only going into the broadly applicable things, not even the niche things :P
<MichaelRaskin>
Then again, just read Engelbart's «Augmenting human intelligence» if you have some optimism to burn
<joepie91>
7) (open-source) authoring tools for interactive visual documentation
<joepie91>
I could probably go on for a while
<jD91mZM2>
That's a lot of ideas
<MichaelRaskin>
Scratch that, a sane idea of learning materials which is not a linear flow of text with some illustrations
<joepie91>
jD91mZM2: aye, and pretty much every single one of them is economically non-viable :P
<joepie91>
(at least without severe compromises that would affect the usefulness of the solution)
<joepie91>
it's not that there are no useful things left to build; it's that the incentives in software development are generally stacked against building useful things
<MichaelRaskin>
We don't even have a DVCS that would be _strictly_ better than SVN
<joepie91>
and heavily biased towards building *marketable* things
<joepie91>
down to all the tooling being optimized for building marketable things
<jD91mZM2>
No easy* useful things then :P
<joepie91>
oh, sure :)
<joepie91>
all of the above are also finicky in some way
<MichaelRaskin>
I would say no easy and easy to specify
<joepie91>
either from a UX perspective, or from a cat-herding perspective, or from a "how the hell do I represent all the information every syntax highlighting system needs in my unified representation":
<joepie91>
... perspective
<jD91mZM2>
Also, I've noticed that people don't usually get nearly as excited for useful things
<joepie91>
I find that it depeends
<joepie91>
depends*
<MichaelRaskin>
I mean, building my Lisp-based OS management I have stumbled upon a few things of the kind «why the hell nobody uses it, it's trivial to implement on any stack»
vmandela has joined #nixos-chat
<joepie91>
jD91mZM2: so, speaking from personal experience in building useful-but-economically-non-viable things, people are not interested if they just get a one-line blurb of what it is, but once you start addressing the problems that it solves and people see things they can identify with, they become interested and start asking "but why did nobody build this yet?"
<joepie91>
(and I mean that literally, that's almost always the first question being asked)
<joepie91>
there's a sort of assumption that useful things are already done and not worth anybody's time, and therefore the only thing to get excited about is shiny things
<jD91mZM2>
I feel like if I post something saying I implemented a Nix parser in Rust, nobody would care that much. But if I tell them I made a VM inside JS written in Rust using a macro that takes valid PHP as input that was written in LOLCODE, people would get all kinds of excited
<joepie91>
jD91mZM2: I'm very much an edge case but "I implemented a Nix parser in Rust" is a good way to catch my attention :P
<MichaelRaskin>
Then again, I am completely hooked on a few use cases for presenting SQL queries over an index of files as a symlink farm, and I am quite sure that stack might be useful to integrate file-indexing with the use of indexed files, but I have no idea how to find out what application would make it useful to people
<joepie91>
jD91mZM2: anyway, distinction between pragmatism and entertainment I guess
<joepie91>
jD91mZM2: people will lose interest in that VM pretty quickly whereas the interest in Nix-in-Rust will probably stick around for much longer
<jD91mZM2>
Honestly it's something I've been thinking of for a while, but never got around to actually trying
<joepie91>
the VM or the Nix-in-Rust?
<joepie91>
:p
<jD91mZM2>
The less insane one :P
<MichaelRaskin>
Speaking of parsers, the world still lacks sane parser infrastructure
<joepie91>
lol
<joepie91>
jD91mZM2: it's the same for me
<joepie91>
I have a long, long todo list
<jD91mZM2>
There is already a haskell lib for doing that, so it's not like people are feeling that it's strictly needed
<joepie91>
and unfortunately I have not yet managed to duplicate myself
<joepie91>
MichaelRaskin: in what sense?
<jD91mZM2>
Figuring out how to duplicate yourself is on your TODO list, I'm sure
<MichaelRaskin>
Well, context-free grammars cannot express the simple idea of «tags in XML match», and they can express a lot of expensive things people don't normally need, and verifying ambiguity is complicated
<joepie91>
hehe, exactly!
<jD91mZM2>
But it could be cool to have a parser, because you could make a formatter with it... but... what else? It's not like people will rewrite Nix in Rust over one day
<MichaelRaskin>
PEG allows to break your mind by a 20-byte grammar definition file
<MichaelRaskin>
Nothing parses Python-style indents in a principled way
<joepie91>
jD91mZM2: judging from the JS ecosystem: having a reliable parser in an accessible language opens the door to a *ton* of necessary and desirable development tooling
<jD91mZM2>
Speaking of parser infrastructure, it's actually crazy how easy Rust macros were to use to create jRust rather than normal tokenizing -> parsing -> evaluating
<joepie91>
in JS, if I want to analyze some sort of thing, usually as part of a bigger project that isn't centered around parsing JS, I just break out esprima/acorn and 10 minutes later that part is done
<jD91mZM2>
I guess it has to do with most of it being done in one step
<joepie91>
vs. spending two weeks writing an ad-hoc parser
<MichaelRaskin>
Yes, one step is a good thing
<joepie91>
this has unblocked a *ton* of stuff for me, and many others
<MichaelRaskin>
But also, a _sane_ parser infrastructure needs a portable definition of grammar
<MichaelRaskin>
Because it _should_ be possible to publish a protocol format specification that everyone has an option to use…
<jD91mZM2>
Is there anything wrong with good old recursive descent parsers?
<joepie91>
jD91mZM2: anyway, if you look at JS developer tooling, you will find that almost all of it relies on a JS parser somewhere in the stack
<MichaelRaskin>
You cannot publish a spec and have it used across the ecosystems?
<joepie91>
often in subtle ways
<joepie91>
having a reusable parser is _really important_ for encouraging the creation of development tools
<MichaelRaskin>
There are parser combinators that generate good recursive descent. Some in Haskell, some in Lisp-family. some in Rust…
<MichaelRaskin>
And all interop is human-translation-based.
<joepie91>
MichaelRaskin: a major problem I've found is that parser formats are typically not sufficiently expressive to go from "a bunch of bytes" to "an AST" without language-specific code
<MichaelRaskin>
Yes, this is a problem
<joepie91>
even more fun when you need a streaming parser
<MichaelRaskin>
PEG, tehcnically speaking, can go from file buffer to some kind of AST, but not the AST you want
<joepie91>
I mean, I regularly write PEG parsers
<joepie91>
I definitely end up having to write glue code to produce a sensible AST :)
<joepie91>
(I use PEG.js, but I've not seen any PEG parsers that would not have the same issue)
<joepie91>
(or well, parser generators)
<MichaelRaskin>
Yes, a portable specification of AST sanification would also be nice
<MichaelRaskin>
But in a way, just having a universally usable definition of a valid protocol message would be a step forward — if you already have a bad AST, messing up the cleanup and not noticing the problem is harder than mis-parsing a corner case from a plain buffer
<jD91mZM2>
I'll try my best to preserve row/cols in the AST. That way the errors can actually tell me where the faulty code lies
<jD91mZM2>
Maybe one could even use them to program a language server or syntax highlighting for nix
<jD91mZM2>
Each token gets its own span number information, but so far errors only get the start, not the end
<jD91mZM2>
So an unclosed string would point to the first quote
<adisbladis[m]>
jD91mZM2: Awesome!
<jD91mZM2>
What mathematical operators does Nix support?
jD91mZM2_ has joined #nixos-chat
jD91mZM2 has quit [Ping timeout: 240 seconds]
<jD91mZM2_>
Computer randomly died out of nowhere. Wish I had ZFS to detect any damages :P
jD91mZM2_ is now known as jD91mZM2
pie_ has quit [Ping timeout: 260 seconds]
pie_ has joined #nixos-chat
<gchristensen>
eh, you probably don't have any
<jD91mZM2>
probably
<jD91mZM2>
At least I commit way too often :^)
<jD91mZM2>
Well, guess what it's time for!
<jD91mZM2>
A macro to parse Nix at compile time :^)
<jD91mZM2>
Actually would help with the unit tests
* jD91mZM2
should be stopped
vmandela has quit [Ping timeout: 240 seconds]
vmandela has joined #nixos-chat
<joepie91>
jD91mZM2: will keep an eye on that, thanks :)
<joepie91>
jD91mZM2: btw, any particular reason you're not using nom?
<jD91mZM2>
joepie91: Mainly because I don't know how to use it and also because I'm secretly 3 years old in the "I can do this without help" phase
<jD91mZM2>
Update: Now we got math and a nix! macro to help unit test stuff
<joepie91>
blaaaaargh.
<joepie91>
serializing objects with circular references is easy.
<joepie91>
deserializing them, as I just realized, is not.
<joepie91>
jD91mZM2: right :P
<joepie91>
I haven't had much of a chance to work with nom yet but it seems pretty nice
<jD91mZM2>
joepie91: The nom description apparently says "programming language parsers are usually written manually for more flexibility and performance"
<simpson>
joepie91: Easiest algorithm for this involves promises. Each time you come to a seam in the recursion, create a new promise for the value. When you've traversed the entire structure and you're done, complete each promise.
<jD91mZM2>
phew
<simpson>
This is, incidentally, exactly how Monte compiles statements like m`def x := [1, x]`.
<joepie91>
simpson: yeah, that's what I was thinking of, but I don't like involving async boundaries
<joepie91>
(which you inevitably end up doing with promises in JS)
<samueldr>
for the longest time, I was sure that joepie91's avatar on github (seen at thumbnail size) was some kind of cartoony ant head :/ just realized it's a pie with a mug
<simpson>
joepie91: Yeah, JS promises don't have semantics amenable to doing this in a single "turn".
<gchristensen>
samueldr: haha yea, cup'a'joe and slice of pie
<joepie91>
simpson: alternate approach I'm considering is to keep a list of 'unfilled references' in the tree that hold placeholder values and, upon completing the first pass, doing a second pass through the structure and replacing all the known references
<joepie91>
feels a bit icky, but.
<joepie91>
samueldr: hehe.
<joepie91>
samueldr: Joe. Pie. 91.
<joepie91>
somebody mspainted it for me years ago on IRC
<joepie91>
and it's been doing its punny job gloriously since then :P
<joepie91>
simpson: anyway, I probably need to think of yet another approach (maybe something depth-first? dunno) given the strict validation semantics of the types that I'm deserializing the data into...
<joepie91>
so I think it's time for me to call it a day and sleep over this
<sphalerite>
joepie91: what's the mug got to do with joe?
<joepie91>
sphalerite: cup of joe
<joepie91>
(cup of coffee)
<sphalerite>
never heard that expression before
<samueldr>
AFAIK it's a US idiom
<joepie91>
yeah
<hodapp>
yeah, kinda rare here but you'll see it on occasion
tertle||eltret has joined #nixos-chat
<jD91mZM2>
TFW all 18 tests pass
<jD91mZM2>
Growing with tests is sometimes like growing with a dog. You don't notice how big it grows until you look back at an old picture.
<jD91mZM2>
In this case the grow = amount of test, and old picture = the usual amount of tests for me, which is 0
<samueldr>
haha
<samueldr>
jD91mZM2: you never answered (I think) about your nix parser implementation
<jD91mZM2>
samueldr: What was the question?
<samueldr>
what are you implementing this in and with
<samueldr>
(to which we jested LOLCODE etc.)
<jD91mZM2>
It's written in Rust, without any parsing frameworks
<samueldr>
quick Qs: are you keeping *all* the input data?
<jD91mZM2>
What do you mean?
<samueldr>
like the comment type (# vs. /*), indent, etc
<samueldr>
especially comments, type and contents
<samueldr>
because if a `nixfmt` was to be implemented, it'd need to know about the comments
<jD91mZM2>
Currently, whitespace is discarded, but span information is preserved per-token
<samueldr>
and possibly indent, use of spacing
<jD91mZM2>
Does not yet support comments, so that's up to you
<samueldr>
(won't be close to looking at this for a while, but good to keep in mind anyway)
<jD91mZM2>
("up to you" meaning you get to chose and I'll implement it, in case it sounded like I meant you'll have to manually parse comments lol)
<jD91mZM2>
s/chose/choose
<samueldr>
well, if one of the goal is "formatting nix code", you'll definitely need to keep the data around :)
<samueldr>
though do note that I have only limited experience with parsers, all using parslet
<jD91mZM2>
Doesn't "formatting" mean you redo all whitespace?
<samueldr>
that's a trap!
<samueldr>
alignment != indent
<jD91mZM2>
I guess I'll keep comments, anyway. Whitespacing can be gathered from the span information, so you don't need both
<jD91mZM2>
Well, it can't yet be gathered from the span information because currently I only give that away on tokenizing and on error. Will fix that too
<samueldr>
really depends if the `nixfmt` format expects to obliterate all whitespace, it's a bit tricky to do right with regards to alignment
<infinisil>
I really want a nix formatter already
<samueldr>
I do too!
<gchristensen>
hard same
<samueldr>
(which is why I tried!)
<infinisil>
Especially to run it on nixpkgs and have it reformat every file perfectly :P
<samueldr>
I'm thinking especially with regards to how technically, \n are whitespace too, should they be re-wrapped? when?
<infinisil>
(I'm looking at you, file that uses tabs instead of spaces, I know you're in there)
<jD91mZM2>
I'm sure my parser is going to break in the weirdest way trying to run it on nixpkgs
<gchristensen>
-1 on that, unnecessary reformats on a projects the size of nixpkgs will cause a lot of problems
<samueldr>
(don't get me started on tabs vs. spaces because I'm sure sparks will fly)
<infinisil>
gchristensen: It's a one time cost, later we can run the formatter on every PR and have it complain automatically
<samueldr>
+1 on `nixfmt` it all *on a long timeline*
<samueldr>
so, new contributions (new files) -> nixfmt. Large changes -> nixfmt
<MichaelRaskin>
Just no
<samueldr>
there'll be a tipping point where most of it will be formatted
<gchristensen>
it isn't a one-time cost, it is an N-time cost for every fork and patch and contributor and backport andon and on
<infinisil>
gchristensen: What problems are you thinking of though?
<MichaelRaskin>
Large changes are complicated to review as-is
<samueldr>
MichaelRaskin: you're right, that should be a step *after* the review, in a separate commit
<samueldr>
(and that's assuming bug-free nixfmt)
<samueldr>
(or before the review, in a separate commit)
<jD91mZM2>
Daily auto format :P
<infinisil>
If nixfmt is working really well, I'd really like the nix community to commit to a single style
<jD91mZM2>
Honestly, it could be easier to review nix expressions if they're well formatted :P
<infinisil>
I don't want to do any more format related comments on PRs
<jD91mZM2>
But yeah it adds burden to each contributor
<infinisil>
If we make it well integrated, maybe into nix itself, then it could work really well
<gchristensen>
big-bang PRs are hard on small projects, near impossible when you have thousands of forks and ~1.5MLOC
<jD91mZM2>
(Not that rust-nix will ever be bug-free, heh)
<MichaelRaskin>
Can it be a commit hook?
<samueldr>
a bunch of different ways could be implemented to reduce the cost for the end-developer
<jD91mZM2>
Can commit hooks be distributed to all local clones?
<samueldr>
and possibly even CI hooks to verify / help
<MichaelRaskin>
Well, the question is how many heads we have across the forks, not the formal number of forks
<samueldr>
I gather there is no way to figure out if two expressions are equivalent with nix right now (tried (a: a) == (a: a) in the repl)
<jD91mZM2>
What exactly what that do?
<MichaelRaskin>
Lambda-calculus equivalence is already undecidable
<infinisil>
*in general
<samueldr>
I'm thinking even if only at the AST level that nix sees, so a `nixfmt` can be checked to be equivalent
<MichaelRaskin>
Ah
<jD91mZM2>
oooo
<infinisil>
Yeah, that needs to be outside of nix though: parse ast -> compare
<samueldr>
yeah, but using the same parser
<MichaelRaskin>
Hm
<samueldr>
especially since it's not formally defined, right? the implementation is its definition, right?
<MichaelRaskin>
nix had eval-only and parse-only
<MichaelRaskin>
maybe parse strictly to XML and compare?
<MichaelRaskin>
Waaait
<MichaelRaskin>
Is «nix-instantiate --parse --strict -E» nixfmt?
* samueldr
checks
<MichaelRaskin>
Maybe not with a good format
<samueldr>
right now it loses all comments
<samueldr>
though it could be used as a way to kickstart one that uses nix's parser, *if* one adds the required stuff
<jD91mZM2>
Umm wait
<jD91mZM2>
Try that and "2 - 1"
<jD91mZM2>
((__sub 2) 1)
<samueldr>
:)
<jD91mZM2>
I guess it's valid nix... Is that a builtin, then?
<MichaelRaskin>
Yes
<samueldr>
» Just parse the input files, and print their abstract syntax trees on standard output in ATerm format.
* samueldr
searches what's "ATerm format"
<infinisil>
I don't think it's all valid nix
<MichaelRaskin>
I think for correctness check it can be good enough
<jD91mZM2>
infinisil: It does run
<jD91mZM2>
And (-5) becomes ((__sub 0) 5)
<infinisil>
But yeah the nix-instantiate parse thing can be used to compare
<samueldr>
oh right, correctness
<infinisil>
jD91mZM2: everything?
<MichaelRaskin>
samueldr: that sounds as if correctness is an afterthought!
<jD91mZM2>
infinisil: Oh, sorry, I thought you meant the __sub thing. My bad
<samueldr>
I was thinking about the nixfmt feature and not the check :)
<infinisil>
Ahh
<jD91mZM2>
MichaelRaskin: Eh, most important thing is getting it to look good. Doesn't matter if it actually compiles or not /s
<samueldr>
though, I guess that given that format, if comments were added in there, it could be possible to format nix expressions, but there would still be some loss of precision (alignment mostly)
<samueldr>
also loss of precision about things like __sub
<samueldr>
and parens use (though removing redundant parens is good)
<jD91mZM2>
> ({ a, b }: 0)({ a = 0; b = 1; c = 2; })
<{^_^}>
anonymous function at (string):166:2 called with unexpected argument 'c', at (string):166:1
<jD91mZM2>
> ({ a, b, ... }: 0)({ a = 0; b = 1; c = 2; })
<{^_^}>
0
<jD91mZM2>
How come ... can be omitted inside package declarations?
<jD91mZM2>
is callPackage simply that smart?
<clever>
the ... just makes it ignore unexpected arguments
<clever>
callPackage wont give it unexpected ones
<jD91mZM2>
Ah
<jD91mZM2>
How does it know what to give?
<clever>
> builtins.functionArgs { a, b, c ? 42 }: a + b + c
<{^_^}>
error: syntax error, unexpected ',', expecting '.' or '=', at (string):166:26
<clever>
> builtins.functionArgs ({ a, b, c ? 42 }: a + b + c)
<{^_^}>
{ a = false; b = false; c = true; }
<clever>
you can query the names of args for a function
<jD91mZM2>
oh
<clever>
> builtins.functionArgs (x: x+5)
<{^_^}>
{ }
lopsided98 has quit [Ping timeout: 255 seconds]
<infinisil>
> isVariadic ({ ... }: 1)
<{^_^}>
true
<infinisil>
> isVariadic ({ }: 1)
<{^_^}>
false
<infinisil>
My favorite magic ^^
<jD91mZM2>
For some reason I'm feeling anxious even though I'm not going to make it run Nix code, only parse it. Don't know why.
lopsided98 has joined #nixos-chat
<jD91mZM2>
(about all these builtins, I mean)
<MichaelRaskin>
Don't worry, NixOS code passes around pkgs, which is a larger attribute set full of various magic
<MichaelRaskin>
Do you feel better about builtins attrset now?
<MichaelRaskin>
(by contrast)
<jD91mZM2>
What do you mean exactly?
<gchristensen>
if you're just parsing, just treat builtins as an attrset.
<elvishjerricco>
I'm pretty new to all this next gen file system stuff. ZFS seems like the best option at the moment though, right? Btrfs sounds like it's having a lot more problems
<gchristensen>
elvishjerricco: zfs is 4 years older with a massive company investing loads of money in to it. people say btrfs is fine. :)
<MichaelRaskin>
jD91mZM2: builtins are not the scary part
<infinisil>
elvishjerricco: Lots of people using zfs, can recommend, also native encryption is around the door
<elvishjerricco>
I was trying to find a quit pros / cons list online but came up short. Just excessively lengthy opinion pieces
<elvishjerricco>
s/quit/quick/
<MichaelRaskin>
Wanting next gen FS is probably not a good way to go. Decide what features you care about first, maybe?
<elvishjerricco>
MichaelRaskin: Oh yea my goal is mostly having something that checksums and allows adding storage without reformatting
<gchristensen>
suse is still supporting btrfs but rhel is not
<MichaelRaskin>
Adding is easy even with ext4 (lvm2 for the win), shrinking is harder (requires umount for ext4)
<gchristensen>
back ~4yrs ago I had very poor experiences with btrfs, I have to assume it is better now
<MichaelRaskin>
It is
<gchristensen>
good
<jD91mZM2>
Are any of you people online right now not using ZFS, raise your hands
<elvishjerricco>
Not yet :)
<jD91mZM2>
^ me too. Gotta get around to it some day
<ivan>
I use XFS
<MichaelRaskin>
Me, BtrFS
<gchristensen>
hmm I have one system using ZFS for three disks ... but not on this machine. vast majority of my systems are ext4. I like ext4.
<MichaelRaskin>
(and ext4 for other stuff)
<elvishjerricco>
MichaelRaskin: Curious if you could give some brief reasons for your choice?
<MichaelRaskin>
I want _one_ thing from FS that ext4 won't give me ever: dynamic inodes
<MichaelRaskin>
For /nix/store
<gchristensen>
yeah :( true
<MichaelRaskin>
I don't want that mess of licensing and out-of-tree stuff with ZFS
<gchristensen>
I thought the licensing thing was settled? maybe not
<MichaelRaskin>
XFS and JFS seemed to dislike what I normally do with /nix/store, BtrFS was OK-ish and I never cared about data loss on /nix/store
<MichaelRaskin>
gchristensen: it is still CDDL
__monty__ has joined #nixos-chat
<MichaelRaskin>
Probably local compile without distribution is legal, use-for-any-purpose seems to be OK with both licenses
<elvishjerricco>
What are dynamic inodes?
<MichaelRaskin>
But this clustercircus guarantees never-in-mainline
<MichaelRaskin>
ext4 has format-time selection of number of inodes (file entries) for the FS
<MichaelRaskin>
You can later extend the size in bytes, but number of file entries is fixed
<MichaelRaskin>
And of course you never remember to check the inode count
<MichaelRaskin>
And debugging Nix stuff often leads to creating huge symlink sets again and again
<gchristensen>
not until you can't make new files and have plenty of free space and bang your head on your keyboard once you realize, oh! inodes!
<MichaelRaskin>
Yeah, took some time the first time
<Drakonis>
gchristensen, zfs has the curse of being cddl and most of the code still being owned by oracle
<jD91mZM2>
Is BrtFS just as stable as ZFS, or is there any chance whatsoever of data loss?
<Drakonis>
btrfs is getting there
* jD91mZM2
heads off to bed
jD91mZM2 has quit [Quit: WeeChat 2.0]
<Drakonis>
rip
<gchristensen>
°°°·.°·..·°¯°·._.·always a chance of data loss·._.·°¯°·.·° .·°°°
<Drakonis>
hahaha yes
<Drakonis>
apparently, there's a legal clause on cddl that lets oracle override the license with another one
<Drakonis>
apparently the openzfs source still has most of the code with the clause
<MichaelRaskin>
Override in non-exclusive sense?
<MichaelRaskin>
Scary stuff would be if it were effectively revokable
<Drakonis>
override as in, "we can release a new version and now every instance with this clause will automatically agree to it"
<Drakonis>
its like gpl or later except it has rabies
<MichaelRaskin>
Wait, GPL X+ works non-exclusively
<Drakonis>
they can release a cddl version that's basically the gpl and it will apply to it
<Drakonis>
shit is crazy
<MichaelRaskin>
I think it should be CLA+auto-upgrade
<Drakonis>
cddl's main issue is that oracle is a fickle master
<MichaelRaskin>
I.e. they can release a new version and everyone agrees that everyone can choose the version to use, even for derived additions not by Sun/Oracle
<Drakonis>
at any moment they can swoop in and ruin it
<MichaelRaskin>
Good question how far they can ruin it
<Drakonis>
the other issue at hand is that the folks that contribute to openzfs are of the uh
<MichaelRaskin>
Of course, providing ZFS+Linux to someone else commercially is probably suable.
<MichaelRaskin>
As in, Oracle can write the complaint well enough for it to survive a few years of litigation
<Drakonis>
"weird variety"
<gchristensen>
" In the case of the kernel, this prevents us from distributing ZFS on Linux as part of the kernel binary. However, there is nothing in either license that prevents distributing it in the form of a binary module or in the form of source code."
<Drakonis>
people that don't like linux because of the license
<MichaelRaskin>
I think this is Ubuntu interpretation
<MichaelRaskin>
Because binary kernel module distribution contains derived works from Linux kernel so must be GPL2
<elvishjerricco>
How does it contain derived works?
<MichaelRaskin>
Compiled binary FS module has to contain quite a bit of information from the specific kernel version…
<MichaelRaskin>
Anyway, as long as you don't want the latest mainline on the day of the release and you don't want to offer paud support for other people's ZFS-on-Linux installation, all this circus doesn't have too many ways of being relevant to you
<elvishjerricco>
Wait zfs doesn't support trim? I don't know much about this stuff but I thought that was really important for ssds?
<Drakonis[m]>
Supposely it does support
<Drakonis[m]>
TRIM is important for ssd longevity and performance
<MichaelRaskin>
With hardware manufacturers, «X is important for performance» usually comes with «and often has weird undocumented implementations violating all the standards»
<Drakonis[m]>
ZoL doesnt do it yet
<Drakonis[m]>
zfs looks like it might not age well due to how tightly coupled it is with solaris code
<elvishjerricco>
MichaelRaskin: Hm but Ubuntu ships zfs as a kernel module. I *think* it ships a binary.
<gchristensen>
ubuntu decided it was okay to do that
<elvishjerricco>
Lol okie dokie
<gchristensen>
not without cause
<gchristensen>
they worked with lawyers and determined it was okay
<MichaelRaskin>
At the same time as other distributions worked with other lawyers…
disasm has quit [Quit: WeeChat 2.0]
tertle||eltret has quit [Quit: Connection closed for inactivity]
<benkolera>
Do you know whether there was actually proper precedence set for compatibility of GPL and CDDL code or is there a loophole with it being a being some weird and separately licensed part of Ubuntu? Or are canonical just kinda hoping that they don't get sued because oracle doesn't care about solaris anymore (i.e https://www.itwire.com/open-sauce/79738-bye,-bye-solaris,-it-was-a-nice-ride-while-it-lasted.html).