> LTO was available in llvm forever, and well predates GCC, clang is just a particular frontend.
For the initial version of this guide, I chose to focus on features as they are exposed in specific tools, as it's easier to pin down a "first available" date that way. Basic LTO for Clang is listed as first available in Clang 2.6, which is also the first LLVM release to officially include Clang.
> It also misses the function summary vs non summary modes, which is fairly important.
Are you talking about the module summaries LLVM uses in its parallel / thin LTO mode, or something else?
Ah hmm, I guess part of the problem is I am less familiar with JVM, CLR, etc. features in this space.
Does anyone know of articles that go into a bit more on precisely the kinds of LTO they offer? I'll update the guide once I understand the situation a bit better.
> From the thousands of open issues (5000+ Web, 1000+ iOS and Android each!) you can clearly see they have an organization problem.
As I said before down thread (https://news.ycombinator.com/item?id=27974054), there’s nothing bad about thousands of issues, quite the reverse in fact. Many are feature requests that may or may not be implemented.
A large number of open issues means the project is growing and many people are have ideas for new ways it can improve.
Many issues are pie in the sky enhancement / feature requests that may or may not be implemented some day. There is no intention to drive the number of open issues to 0 just for the sake of it.
As long as Element and Matrix continues to grow, I expect the number of open issues will grow indefinitely, and that is a sign of success.
I don't think you're fully appreciating the context here... The moderator of that community had been trying over and over, both privately and in public, to get this person to follow community norms for years, but they just would not do so.
To me, who has been in that community for years, it was entirely the correct action to take. Moderation is hard and no fun at all, but it needs to be done, or else a community will descend into madness.
Thanks for mentioning all these great articles and efforts! :) I hope more people will explore everything you've listed here. As you say, we need to go even further and more radical than e.g. GNU to address the tar pit we find ourselves in today, and so the more we can get people imagining what the future could be like, the better.
> (Side note: former Mozillian here, and there's no real excuse for why the Firefox contribution process itself hasn't worked like this for the last 10 years except for Mozilla's infamously poor competence at almost all things re project management.)
As a former Mozillian myself, I agree it's quite sad that so many paths that would have eased contribution and supported a universe of surrounding projects were sacrificed on the altar of Firefox. The management team at Mozilla doesn't seem to understand the huge impact the organisation could have had by supporting a whole ecosystem and way of building / thinking about software.
> The Malleable Systems Collective <https://malleable.systems/> was introduced this past spring, but seems to have fizzled since then, possibly due to COVID-related dampening effects.
(With my Malleable Systems Collective organiser hat on...) I think it's been a difficult year for most people, and it has been harder than I hoped to find time for this effort in 2020. Actually though, the website is a bit deceptive: while the blog has been pretty quiet, the Matrix room (https://matrix.to/#/#malleable-systems:matrix.org) has an active community regularly trading ideas in this space.
I'm hoping to have some more time and energy in 2021 for both experiments and writing that add to both the collective and the more general conversation that you are highlighting here.
As you’ve surmised, the user / workflow author is meant to be the same person.
When it says “authors must retain ownership”, this was mostly meant as a reaction against platforms like IFTTT and marketplaces like browser extension galleries that may bring sharing restrictions, vendor lock-in, etc. So it’s trying to argue for more openness at least being available as an option to the hybrid user / workflow author.
For cases where the user / author wants to be restrictive and lock down who can use the work, the mission is mostly silent on this front.
Personally, I would hope most would see value in openness, and known approaches for enforcing restrictions (like DRM) are quite ... unpleasant.
I am hopeful better schemes can be created for those who want such things, but it seemed a bit beyond the core focus of the mission (which is already quite ambitious). Thanks for the feedback!
I am not sure why the names are randomized, but you can still check in the folder if you wish. The outer profiles.ini is all you need to map in the right folder name (on Mac / Linux at least...).
There is no real "spec" of the Pepper APIs, just API docs. While those might be of high quality, it still depends on many implementation details, so it seems like it would be challenging for another browser to duplicate.
I don't think your anger about multiple assignment is valid.
I also use the Dev channel regularly, but I don't think it's fair to expect it to meet a high bar of quality. Typically issues are corrected within a few days.