The entire CNCF apparently has a no AGPL policy. We just found out this week that we cannot update and redistribute Grafana anymore with our CNCF projects, (or if we do we will be on very shaky legal footing.)
> a Linux Foundation project that was founded in 2015 to help advance container technology[1] and align the tech industry around its evolution.
> It was announced alongside Kubernetes 1.0, an open source container cluster manager, which was contributed to the Linux Foundation by Google as a seed technology. Founding members include Google, CoreOS, Mesosphere, Red Hat, Twitter, Huawei, Intel, Cisco, IBM, Docker, Univa, and VMware
I haven't read the details, or ever seen this policy before (I'm new to both projects) but it was summarized by one of our counterparts at the Linux Foundation here:
Tl;dr: licenses must be approved for use, and the CNCF has this list of allowed licenses, AGPL is not on it. The CNCF is in the business of distributing permissively-licensed software is the short version I guess. I don't understand, I don't work on the legal side, I am a dev and I support end users.
It seems if your Apache 2.0 licensed project needs to modify and distribute as modified an AGPL project, (which for Grafana it seems likely we will need to do at some point, the Linkerd project already has needed to do this if I understood correctly) then you cannot distribute them together, or something about this becomes much more complicated. Chris says they are going to try to work something out, but when a component has made a decision to re-license with a restrictive-copyleft license such as AGPL,
I don't know what there is that can be done to fix it. I hope they come up with something.
Maybe the CNCF adopts AGPL too, (which would mean that then all those "viral-GPL" FUD-spreaders will have been right...) that seems counter-productive if that is the outcome. (So I hope they come up with something else than that!)
Everyone is within their own rights to do whatever they want with the output of their own labor, I just wanted to help dispel the notion that only exploitative companies are affected by this change.
> Proponents of copyleft licenses have argued that these licenses prevent companies from exploiting open source projects by building proprietary products on top of them. Instead, we have found that successful projects can help companies’ products be successful and that the resulting profits can be fed back into those projects by having the companies employ many of the key developers, creating a positive feedback loop.
It's like Van Halen and the brown M&Ms thing. It determines if the author of a C++ lexer, syntax highlighter, etc., read the Standard. Try splitting a digraph with \ and a newline.
It lacks type safety because it's not possible to distinguish between an sc_array and a pointer so there's no way of detecting that someone passed a char * that nobody had ever called sc_array_create on to sc_array_add for example.
The alignment is broken because nothing in the C standard guarantees that the elems member of sc_array will be aligned correctly for any possible element type.
I also spotted another problem, in sc_array_init the code `void *p = a` is also not guaranteed to work. In an example snippet such as `int iv; sc_array_create(iv, 0);` expands to `sc_array_init(&iv, sizeof iv, 0)` so the type of the expression `&iv` is `int *` which is then being converted to `void *` in the function which is actually not allowed by the standard. This is also the reason why if you were writing a wrapper around realloc which exited if the allocation failed you would still have to pass in the current pointer with void * and return the new pointer with void *. This could be applied here actually as an easy fix but it indicates even further to me that the author of the library is taking a very leisurely approach to writing conforming C. This pattern also appears in the other two functions though and I'm not sure if in those cases it's something which can be easily fixed.
fast, simple, scalable, modern, high performance, easy to use, enterprise-grade, secure, production-ready, new generation, lightweight ...
These are common words I see in the first paragraph of readmes. If people can avoid these, they’ll write better introductions. No marketing, no subjective words. Otherwise, I feel like someone is trying to sell me that product.
I'd expect a fast json parser to be harder to use than an easy-to-use or simple one. But if I need to eke out maximum performance on something I'm going to skip the ones that don't have fast in the description - it means the project's goals aren't aligned with my use case. If it's a web project then I'm going to focus on parsers that have have actually considered security over the ones that haven't.
These are all important words for describing projects.
Claiming "fast" implies that performance is a project goal, possibly even tracked over time as a metric, and that there's probably a comparison deeper in the README or elsewhere. It probably also means that when it comes to tradeoffs (compile time, code size, binary size, ergonomics, maybe even strictness/correctness), runtime speed is the preferred option.
I think production ready on its own has value because it sets the stage of what to expect.
There's a very big difference between a project being production ready or not. Production ready (to me at least) means the project has been thoroughly tested on a live site and is in a position where you can take it as is and run it in production with confidence that it's going to work.
For example I have a Docker + Flask example starter kit project at https://github.com/nickjj/docker-flask-example and the GitHub description is "A production ready example Flask app that's using Docker and Docker Compose.". In this context to me that says it's using multi-stage builds, env variables, deals with static files in a way that's cacheable (md5 hashes, etc.), has tests and overall you can expect to see patterns that work well in both dev and prod. The README goes over those details too in case you didn't infer that from only "production ready" too.
Plot twist: It took me longer to write the README than create the whole project.
I agree in general, except for `production-ready` which I deem useful information. Of course, it is only the maintainers‘ assessment on the state of the project and thus needs to be validated further by myself. But IMO that adjective signals that I can expect the author to be happy with the current API and behavior and can assume it will be relatively stable; probably battle-tested.
I think "production ready" is essentially impossible without also being able to say "I/my employer/foocorp is running this in production" unless you're not allowed to say it for legal reasons. I think it would take a very experienced developer to predict in advance every issue they'd run into putting something into production.
The definition you gave is exactly how I would read `production-ready`. I might be overly optimistic in assuming that this is the case whenever someone uses the term, though.
> I think it would take a very experienced developer to predict in advance every issue they'd run into putting something into production.
I am not sure whether that can be expected from any project that exceeds a very narrow scope and/or if which it’s correctness can potentially be mathematically proven.
This sounds right, though it doesn't have to be. These type of words signal the author's intent and when
1 - justified by the actual deliverable
2 - substantiated with concrete data
can be very useful. They can help create the right expectation. Unfortunately, they are more often misused or abused than applied correctly.
> How many people intend to make slow, outdated, insecure software?
The point is that some authors may claim simplicity, some may claim performance, others more security and so on. It is rare to have all adjectives thrown in - and easy to discard when you see them.
>because by now we’re primed to ignore those claims.
Unfortunately, we don't always. If we were ignoring them all, then we wouldn't care. It is that we can't help read and interpret them and have our expectations set up; hence the disappointment when it turned out to be just words.
Actually, Java has great tooling, JVM is very nice, it has great potential for high performance code generation. It has everything for debugging. But at the end of the day, language is driving people to write bloated software.
I just wonder, how come e.g Linux kernel code 100 times more readable than any project in Java? More importantly, how did we come to this point that we accept bloated/unreadable code in the name of higher/better languages?
Linux isn't readable because of C. My god, just go look at the source code of most GNU projects like glibc or gcc if you want to disabuse yourself of that notion.
Linux is highly readable because Linus imposes readability on it through sheer force of will, and because they are willing to sacrifice driver API on the altar of clean code. The result is a very efficient and readable kernel that hardly anyone uses in the environment with the most complex and heterogenous hardware i.e. desktops and mobiles. Android doesn't really use Linux these days. Since some years it has developed its own stable driver ABI that bypasses the kernel for most things.
If all Java codebases were run by a dictator-for-life who could sacrifice trifling details like adoption in order to get the most readable code possible, you'd find you'd like them a lot more too. And a few such codebases are actually like that! Look at the source code of the JDK itself sometime (not the bits by Doug Lea though), or Guava, or really quite a few open source Java projects have readable and nice code.
Java won by its portable deployment model, stack traces, GC, libraries and security sandbox safety. In over two decades, very few other platforms have come close to its promises. C# is perhaps much better, but has stronger proprietary ties and vendor lock-in.
Java became overcomplicated by frameworks and design patterns, so has always felt bloated and slow. But has worked best for business logic. Though is maybe behind COBOL thus far, and tends to hide/obscure logic. No two java designs looks the same, scales well or converge to clear consensus. The language did lower the bar for what cheap programmers could accomplish faster though.
Java style verbosity hurts readability. That’s the most important issue with Java imho.
Take a look at a http server one in Java and one in C. Readability difference is crazy.
My company is in transition from Java to C, for bunch of stuff just for performance reasons. So, I debug similar projects time to time both in Java and C, http server, in memory cache, iot server etc. After seeing both, I just think although Java has great tooling, it drives developers to write unreadable code.
I’m not a backend java dev but whenever I take a look at java web projects which use spring/jsf/jsp etc frameworks, docs say to handle a request, write a method with that signature, we’ll call it when there is a http request. I always want to know enterence/exit points of a network message but that is impossible with these fancy frameworks. It is pure magic.
> You need mechanisms for helping people learn "This is not welcome on HN. This is not how we do things here."
Can we use flags for this purpose?
Problem is even though a comment does not violate any rule, it gets down-voted as hell if you say something that majority of people would not like. e.g there are posts about hyped programming languages, go check out down-voted comments, most of them does not deserve to be down voted.
There some topics, these topics have “fan-boys”, so even a comment is constructive, it gets down-voted.
You already show disagreement with comments. If a comment violates a rule, we can flag it. If a comment does not get up-votes, it moves to bottom of the page. So, I think down-votes don’t add any value to HN.
As someone who gets downvoted probably more than average, I don't agree with you. Downvotes are the least problematic way for people to tell me they have some problem with my comment and minimizes the fallout from me having to try to navigate gender politics as part of the mix.
It would be vastly worse for men to only be able to express sexist garbage by openly attacking me and trying to find some plausible excuse for hostility that is sometimes rooted in "She won't date me!" basically.
I'm a very controversial figure in part because I am getting healthier when that is not supposed to be possible and the world generally has a big issue with me because of that reality. HN has handled my "disruptive' presence better than any other forum I've been on. I've been banned from several forums and I've had mods elsewhere tell me that the abusive treatment heaped on me by others that was a clear violation of the stated rules was not the problem, the problem was somehow my behavior.
Since I'm not making any of that up, I'm kind of painted into a corner here socially and I've spent a lot of time trying to figure out how to not end up essentially murdered over it, like Semmelweis was.
I do everything in my power to behave in accordance with the rules and blah blah blah, but I'm a woman and HN was as much as 98 percent male when I joined and I'm getting healthier when that isn't supposed to be possible and so forth. And HN is the only forum that is able to cope with that constructively and help me talk to people who are knowledgeable about areas of science that are pertinent to my needs as someone trying to survive in the face of an incurable genetic disorder.
I say all kinds of things that are not "popular" or even socially acceptable and as long as I am not violating the rules of civility, the mods here don't have a problem with me being here and that's extremely unusual. Most mods are all too happy to just get rid of me as the easy answer to their problem while not caring that this is de facto a polite way to quietly commit murder against someone whose crime boils down to "I am a scientist who is doing cutting edge work and my credentials include I'm a former homemaker and spent years homeless."
It sucks to be me. It sucks majorly for a long list of reasons.
And most forums find me intolerable and HN is willing to let me stay and that's literally life saving for me.
So I feel strongly that I am the ultimate test case for how well their rules work. The entire forum can literally think you are nuts and you can say things here that people literally believe is you being a deluded fruitcake making shit up, and if you behave you can stay.
So I think they are doing something amazingly well that's incredibly hard to do and I'm a huge fan in part because it has helped to save my life.
I'm sure there is room for improvement. I'm also equally sure no one else on the planet does it better.
Even though I find myself in disagreement with some of your posts on here, I still value and enjoy your presence here. The internet shouldn’t be an echo chamber. HN has meant a lot to me too, so I can relate with you on that. Have an upvote, and an amazing evening!
e.g : https://opensource.google/docs/using/agpl-policy/