3 ms·
I don't like the fact that it is closed source but not having source code does not stop me from utilising it on a personal basis. I think it makes sense to use
by 3xblah 7y ago
I don't like the fact that it is closed source but not having source code does not stop me from utilising it on a personal basis. I think it makes sense to use it in this capacity and learn the language as best one can in the event that an open source option besides kona does someday become available. k is one of the very few closed source programs I use.
It is interesting how the closed source issue is consistently raised on HN with respect to k when there are numerous other examples of closed source software used by HN readers where I never see this issue raised. In those cases it does not seem to be important. For some reason however, it seems availablity of source code is important to some folks in the case of k.
I am curious; What would you do with the source code? Is it an issue of verifying what the software is doing, or perhaps being able to modify the software or make "fixes"? Is it something else? Maybe you simply want a free option for commercial use. If the later, please disregard my curiosity.
For me the issue I have with k being closed source has always been ports, i.e., limited OS support. They used to have a FreeBSD port many years ago, but today there is no support for OS other than Windows/Solaris/Linux, e.g., NetBSD.
- adrianN 7y agoI'd never use a closed source programming language because it makes me dependent on the vendor. With FOSS, if the original company goes away I can pay someone else to keep the software running on a modern computer. With closed source software I don't have that option.
- 3xblah 7y agoNot disagreening with you, but in addition to the more recent versions, I run an old version of k from around 2000, and it keeps running even with the latest kernels and hardware, thanks to availablity of legacy Debian libraries.
- adrianN 7y agoAt some point in my career I was forced to use a closed source compiler from the early nineties. With each new version of Windows it got harder to keep it running. We also discovered bugs in the compiler and had to rewrite our code to avoid them. I quit that job eventually, but I imagine that in one or two more Windows iterations the developers will be forced to compile inside a VM.
- anonu 7y agoHaving code be free and open is for all the reasons you mentioned. Additionally, my thinking is that if you want wider adoption you will need to be open. Building a community around a language or platform starts with the "hackers" who are curious about the code and want to contribute. The guys who license kdb/q probably make more money today from service/consulting agreements and not the software licenses. So it's to their benefit to go open (a la MongoDB) Also, if you're building a tech stack from scratch - you want it to be "clean". You don't want to muddy it with expensive/onerous software licenses.
- geocar 7y ago> The guys who license kdb/q probably make more money today from service/consulting agreements and not the software licenses. So it's to their benefit to go open (a la MongoDB) It's a public company, so you can go check: https://www.firstderivatives.com/wp-content/uploads/2019/06/First-Derivatives-plc-Annual-Report-2019.pdf https://www.firstderivatives.com/wp-content/uploads/2019/06/... Software earns more than consulting, and the profit is better too. Just because Mongo isn't good enough to make money on its own merits doesn't mean anything. > Also, if you're building a tech stack from scratch - you want it to be "clean". You don't want to muddy it with expensive software licenses. I've been in probably a hundred funding and acquisition meetings at this point in my life, and this has literally never come up.
- bakul 7y agok (specifically k3) runs on FreeBSD if you use linux emulation. The same is true of q. IIRC, there are no limits on the 32 bit version of q (unlike the old k3). kona is more portable but needs work.
- 3xblah 7y agoI have an old license for a 2.x version which removes the workspace limits. /emul/linux is how I use k on NetBSD. However I hesitate to rely on Linux emulation because it does not seem to be something that is important to current BSD developers. If I am not mistaken, both OpenBSD and Dragonfly have removed it.