865 karma · joined June 4, 2010
Here’s Tamir’s call for action https://www.linkedin.com/feed/update/urn:li:activity:7419994...
Summary of the KX Community Edition License Agreement:
Key Points:
What you get:
- Free license to use KX software for personal or internal business purposes only
- No support or maintenance services included
- Software provided "as is" without warranties
Major restrictions:
- NO commercial use
- Cannot sell, distribute, or monetize any product that uses or depends on this software
- Cannot bundle it with commercial products
- Cannot reverse engineer, modify, or create derivative works
- Cannot remove copyright notices or trademarks
- Software may phone home to verify valid license
Important limitations:
- KX's liability capped at $100
- They disclaim all warranties including fitness for purpose
- You must delete software if agreement terminates
- Subject to export control laws
- KX can audit your compliance
Legal terms:
- Governed by New York law
- You retain no IP rights in the software
- Confidentiality obligations for 5 years
- KX can terminate at any time
Bottom line:
This is a restrictive free license meant for evaluation/personal use only. Any commercial use or distribution is strictly prohibited. If you need commercial rights, you'll need a different license.
Another open source app that I’ve been using to practice is https://github.com/sightread/sightread
As a first-time Hi-Fi headphone buyer, the reviews on Amazon and Youtube didn't surface the nuances of the different headphone models using quantitative information as DIY-Audio-Heaven does.
It's an early prototype to gather feedback around the ergonomics of the interface and the manifest format, and I would love to learn if people might find it useful enough for the use cases where LFS falls short.
That said, I built the bash version as a proof-of-concept with the idea of implementing it using Zig once I'm happy with the tool's usability.
Here is a link to the pdf: https://dl.acm.org/doi/pdf/10.1145/3546935
I wonder what other projects are using it in the wild.
The defaults do not seem to match what the [Filesystem Hierarchy Standard] is proposing, but they do seem reasonable:
# user data (/usr/share)
XDG_DATA_HOME="${XDG_DATA_HOME:-$HOME/.local/share}"
# config files (/etc)
XDG_CONFIG_HOME="${XDG_CONFIG_HOME:-$HOME/.config}"
# cache files (/usr/share)
XDG_CACHE_HOME="${XDG_CACHE_HOME:-$HOME/.cache}"
# state files (/var/lib)
XDG_STATE_HOME="${XDG_STATE_HOME:-$HOME/.local/state}"
[Caddy's Dockerfile]: https://github.com/caddyserver/caddy-docker/blob/master/Dockerfile.tmpl#L40
[Filesystem Hierarchy Standard]: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard - shellcheck and shfmt for linting and formatting
- sub for organizing subcommands
- bashdb for debugging scripts interactively via the VSCode extension
I'm still missing a way to share modules with others like it can be done with ansible/terraform, but I have not found an optimal way to do it yet.[shellcheck] https://github.com/koalaman/shellcheck [shfmt] https://github.com/mvdan/sh [sub] https://github.com/qrush/sub [bashdb] http://bashdb.sourceforge.net/ [vscode-bash-debug] https://github.com/rogalmic/vscode-bash-debug
Rules were established after the “flash crash” of May 2010 to govern when trades should be canceled. Knight’s buying binge did not drive up the price of the purchased stocks by more than 30 percent, the cancellation threshold, except for six stocks. Those transactions were reversed. In the other cases, the trades stood.