41–50 of 68 posts
Earlier quoted context omitted.
There is also Blast (golang), built on top of Bleve. - https://github.com/mosuka/blast - http://blevesearch.com/
Yeah but it's golang, so it's kinda like java, so I see no pros in it TBH.
Earlier quoted context omitted.
There is also Blast (golang), built on top of Bleve. - https://github.com/mosuka/blast - http://blevesearch.com/
Yeah but it's golang, so it's kinda like java, so I see no pros in it TBH.
Are you maybe trying to get at the difficulty of tuning the JVM?
Earlier quoted context omitted.
Yeah but it's golang, so it's kinda like java, so I see no pros in it TBH.
There are a lot of differences between Golang and Java. As much as I dislike writing Java when I have a choice, the JVM (with Java or whatever else on top) is a very capble tool... Could you explain what you mean by there being "no pros"? Are you maybe trying to get at the difficulty of tuning the JVM?
golang is kinda a java alternative. a db/search-engine in java/golang kinda sucks (it will under pressure)
Earlier quoted context omitted.
Remind me what's wrong with GPL, here? You can't repackage and resell it?
You can't include it in your code and sell your software without distributing the source.
Earlier quoted context omitted.
You can't include it in your code and sell your software without distributing the source.
Is there actually precedent for a GPL library, clearly setup to be consumed with an API, to require GPL of the whole binary? On the one hand that's clearly not the case in the Linux API, on the other hand the LGPL exists. But was curious if this is actually settled or just too murky to live with.
Earlier quoted context omitted.
You can't include it in your code and sell your software without distributing the source.
Is there actually precedent for a GPL library, clearly setup to be consumed with an API, to require GPL of the whole binary? On the one hand that's clearly not the case in the Linux API, on the other hand the LGPL exists. But was curious if this is actually settled or just too murky to live with.
An explicit license exception for the syscall interface, stating that calling it from userspace is freely allowed: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
And modules, e.g. drivers, have various statements from Linus on how they're not necessarily considered derived works of the kernel/linked to the kernel, e.g. http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.... or http://lkml.iu.edu/hypermail/linux/kernel/0312.0/0670.html
Earlier quoted context omitted.
Remind me what's wrong with GPL, here? You can't repackage and resell it?
You can't include it in your code and sell your software without distributing the source.
Earlier quoted context omitted.
Is there actually precedent for a GPL library, clearly setup to be consumed with an API, to require GPL of the whole binary? On the one hand that's clearly not the case in the Linux API, on the other hand the LGPL exists. But was curious if this is actually settled or just too murky to live with.
The Linux kernel has explicit rules for the cases where it allows it: An explicit license exception for the syscall interface, stating that calling it from userspace is freely allowed: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... And modules, e.g. drivers, have various statements from Linus on how they're not necessarily considered derived works of the kernel/linked to the kernel, e.g. http://linux…
https://en.wikipedia.org/wiki/GNU_Readline#Choice_of_the_GPL...
This is why I always do libs as LGPL but it seems strange to me that it's even needed. If I've defined a proper opaque API, to be consumed by external code I know nothing about, it's strange to then argue that library callers are derived works and LGPL is explicitly needed.