Related, have there been any 'truly open-source' forks of Grafana since their license change? Or does anyone know of good Grafana alternatives from FOSS devs in general? My default right now is to just use Prometheus itself, but I miss some of the dashboard functionality etc. from Grafana.
Grafana's license change to AGPLv3 (I suspect to drive their enterprise sales), combined with an experience I had reporting security vulnerabilities, combined with seeing changes like this[1] not get integrated has left a bad taste in my mouth.
AGPLv3 is a completely valid choice for an open source license, and (not that it was necessarily questioned, but since critique of pushing enterprise sales comes up,) having a split open source/enterprise license structure is not particularly egregious and definitely not new. Some people definitely don't like it, but even Richard Stallman is generally approving of this model[1]. It's hard to find someone more ideologically-oriented towards the success and proliferation of free and open source software, though that obviously doesn't mean everyone agrees.
I'm not saying, FWIW, that I think AGPL is "good", but it is at least a perfectly valid open source license. I'm well aware of the criticisms of it in general. But if you're going to relicense an open source project to "defend" it against abuse, AGPL is probably the most difficult to find any objection to. It literally exists for that reason.
I don't necessarily think that Grafana is the greatest company ever or anything, but I think these gripes are relatively minor in the grand scheme of things. (Well, the security issue might be a bit more serious, but without context I can't judge that one.)
To be fair, AGPLv3 is a very valid open source licence.
Now, poor and bad behaviour from the prom maintainers is a very fertile subject. If you want to see some real spicy threads check out the one where people raised that Prom’s calculation of rate is incorrect, or the thread where people asked for prom to interpolate secrets into its config from env cars - like every other bit of common cloud-adjacent software.
Both times prom devs behaved pretty poorly and left really bad taste in my mouth. Victoria Metrics seems like a much better replacement.
AGPL prevents from wide product adoption, since corporate lawyers caution against relying on AGPL products because it is easy to violate the license terms and being sued after that.
It's not possible to sell non-FOSS modifications to AGPL-licensed software. I think that's intended. It's not antithetical to Open Source, quite the opposite in fact.
Yeah, but lawyers (and companies where these lawyers work) are afraid of licenses with unclear or vague terms such as GPL, LGPL, AGPL, BSL, etc. They prefer to deal with software licensed under clear and concise open-source licenses such as Apache2, MIT and BSD.
Companies care about open source if it helps them increasing their revenue:
- If they use open source code in their commercial products, then they care about the ability to freely use the code without legal consequences.
- If they develop open source product, then they care about increasing the adoption rate of the product.
In both cases truly open source licences such as Apache2, BSD and MIT, work the best. Copyleft licences with some arbitrary restrictions on code use prevent from wide adoption of the licensed project.
There is only a single well-known exception - Linux kernel with GPL v2 license. Commercial companies have to figure out how to use Linux kernel in their commercial products because there is no good alternative.
Maybe I should start insisting on the term "FOSS".
Pushover licenses ("truly open source") enable the exploitation of FOSS developers in the name of easy profit for the people building proprietary software around it, while Copyleft licenses ensure that this does not happen, granting each user the essential freedoms. The restrictions are not arbitrary, they exist precisely to ensure that these freedoms cannot be taken away from anyone. If this hinders widespread adoption by companies, it just means that those companies didn't plan on respecting the essential freedoms.
Freedom is the ability to use the open source code without any restrictions. Copyleft licences restrict the freedom. These licences sound good in theory (let's prevent from unpaid use of the code in proprietary products!), but they work not so good in practice (why bothering with legal headache related to copyleft-licensed code if it is easier to use BSD-licensed code?). This prevents from wide adoption of copyleft-licensed products.
You're misinterpreting it. Integrating FOSS code into a proprietary product is what restricts the user's freedom. Copyleft licenses prevent this restriction. And yes, indeed, why bother working for freedom if it's easier to not have freedom?
> Integrating FOSS code into a proprietary product is what restricts the user's freedom. Copyleft licenses prevent this restriction.
This is like saying "black is white".
Users are free to use any products - open source and proprietary. They don't care about licenses most of the time - they prefer the product with better usability. Copyleft licenses prevent from creating proprietary product with better usability on top of open-source product with mediocre usability. E.g. copyleft licenses restrict users' freedom to use the best product - they force users dealing with the mediocre product.
Take a simpler example. If you have the freedom to imprison me for no reason, you can take away my (literal) freedom. Now you are free, but I am not. Because of this imbalance, the freedom to arbitrarily imprison people is an unreasonable one. Everyone should have as much freedom as possible, and everyone should have the same "amount" of freedom, if you will, so restricting others is out of scope. It's not just about your own freedom, don't be selfish! And besides, what ethically good person would want to lock people up for no reason?
When you are creating proprietary software, you are asking your users to let them be oppressed by you. You are asking them to give in to potential surveillance, planned obsolescence, manipulation, extortion and a variety of other injustices. And when you charge a price for your proprietary application, you are asking your users to pay for this mistreatment. What value does "the best product" really have, when you pay for it with your wallet and your freedom?
Your antique monetization scheme does not align with the values of Free Software. Should you restrict your users' freedom, or fix your monetization scheme?
> combined with them not being a good steward for changes like this[1] left a bad taste in my mouth.
What they did wrong with this PR? It seems eventually they realized the scope was much bigger, requiring changes on both the frontend and backend, and asked potential contributors to reach out if they're interested in contributing that particular feature (saying between the lines that they themselves don't have a use, but they won't reject a PR).
Seems like they didn't need it themselves, and asked the community to contribute it if someone really wanted it, but no one has stepped up since then.
Not the OP but I have done similar things. Claude has a workspace option that let's you preset a set of documents (here the documentation of the library used) and a system prompt to be included when starting a new chat in the given workspace.
Those will be in its, fairly large, context window (overall, independently of its intelligence, I have found Claude current UI to have an edge when dealing with files).
IMHO, he created RAG from documentation to provide more context for Claude, so he then can call Claude with a task like "Generate bindings in Rust language for C++ class Foo from the Bar library.".
Also, make sure your TLS certificates are hard-coded/pinned in your application binary. Just like the network, you really cannot trust what is happening on the user's system.
This way you can ensure you as the developer have full control over your applications' network communication; by requiring client certificates issued by a CA you control, you can assert there is no MITM even if a sysadmin, user, or malware tries to install a proxy root CA on the system.
Finally, you can add binary obfuscation / anticheat mechanisms used commonly in video games to ensure that even if someone is familiar with the application in question they cannot alter the certificates your application will accept.
Lots of e.g. mobile banking apps, etc. do this for maximal security guarantees.
In practice pinning tends to be very "best effort", if not outright disadvantageous.
All our apps had to auto-disable pinning less than a year after the build date, because if the user hadn't updated the app by the time we had to renew all our certs... they'd be locked out.
Also dealt with the fallout from a lovely little internet-of-things device that baked cert pinning into the firmware, but after a year on store shelves the clock battery ran out, so they booted up in 1970 and decided the pinned certs wouldn't become valid for ~50 years :D
Pinning is very complex, there is always the chance that you forget to update the pins and perform a denial of service against your own users. At the point where the device itself is compromised, you can’t really assert to anything. Furthermore, there is always the risk that your developers implement pinning incorrectly and introduce a chain validation failure.
Lots of apps use the anticheat/obfuscation mechanisms added by mobile apps are also trivial to bypass using instrumentation - ie frida codeshare. I know you aren’t implying that people should use client side controls to protect an app running on a device and an environment that they control, but in my experience even some technical folk will try and to do this
This is way overkill, unless you are making a nuclear rocket launch application. If you can not trust the system root CA, the whole internet breaks down.
You will also increase the risk that your already understaffed ops-team messes up and creates even worse exposure or outages, while they are trying to figure out what ssl-keygen does.
> Moreover, the fontations platform, which is the Rust framework Oxidize is producing, will unify font compilation and consumption, reducing the number of places new font-format features need to be implemented from three (FontTools, FreeType, and HarfBuzz) to one (Fontations), which would reduce development cost and overhead.
Will FreeType and HarfBuzz remain supported as C/C++ projects long-term, I wonder? Asking as someone who depends on these and doesn't want to introduce a dependency on a Rust compiler :)
Anecdotally, I notice a lot of game developers avoid FreeType and Harfbuzz entirely, instead opting for much worse text rendering in the form of stb_truetype.h only (Dear Imgui uses this, for example) - which 'is nice because it is a single header C file' but sucks with international languages; many people use SDFs for similar reasons.
I think the proposed move to WASM fonts, if done right, could make it easier to reduce the amount of code people need to render fonts (if the WASM font does the heavy lifting, and a small C program could render it) and alleviate this trend of people not using a good text rendering stack
I wouldn't worry about it. I don't see evidence that these Rust libraries have the kind of uptake that is alleged in the article. I think we'll be stuck with Freetype and HarfBuzz for a long time.
I have been hacking on a Rust program recently and I am using Freetype and Harfbuzz via FFI because the Rust packages he names don't appear to be mature yet.
That only helps you if all your targets are also actively supported by upstream. It also limits optimization opportunities, mainly removing parts of the library your code doesn't need.
I live 15 minutes from downtown Phoenix, and it took them 2 years to expand to my location. Over 4 years after Waymo launched beta testing here..
Waymo cannot take me on the freeway (backstreets only)
Waymo cannot go to the entire city of Peoria, Surprise, Goodyear..
Waymo cannot go to the entire western half of the state.
If you live 30 minutes from the downtown city centre, there is a 30% chance Waymo can go there. Waymo serves higher-end areas only today (Scottsdale, Tempe, Chandler) - if you live in a poorer area, no Waymo for you.
I have family who lives in Scottsdale and Surprise, Waymo can't take me there.
My dentist is less than a mile from my house, Waymo can't take me there - but can take me to a fashion mall in chandler.
Is it better than Uber/Lyft? Experience wise, sure, but their snail's pace expansion is disheartening. Not to mention the freeway issue.
If you're looking for interesting Zig codebases to read, you might be interested in our low-level audio input/output library[1] or our module system[2] codebase - the latter includes an entity component system and uses Zig's comptime to a great degree to enable some interesting flexibility (dependency injection, global view of the world, etc.) while maintaining a great amount of type safety in an otherwise dynamic system.
I see this type of thinking a lot - where someone assumes that 'in a good natural environment' all animals are just peacefully living their lives and thriving. And to some extent, sure, animals in a rain-forest are gonna thrive better than in an industrial wasteland.
People have a romantic view of nature. Nature is fucking _brutal_, unforgiving, and horrific. Starving to death, living with severe infections, broken limbs, chunks of flesh missing, and hopefully reproducing before you meet your fate - that's how most animals in nature live out their lives.
As humans, we've gained the unique ability to greatly control not only our environment, but also other living creatures' environments, and 'unnatural' is not inherently bad. Nature is, more often than not, extremely horrific for living things.
Could we live in a decent environment, where the food paste we eat tastes pretty good and keeps you at optimal health - somewhere between starving and overweight? certainly possible, some pet owners do this. But that's not natural, that's just 'optimal for long-term health' - which is only one input to life happiness.
Grafana's license change to AGPLv3 (I suspect to drive their enterprise sales), combined with an experience I had reporting security vulnerabilities, combined with seeing changes like this[1] not get integrated has left a bad taste in my mouth.
[1] https://github.com/grafana/grafana/pull/6627