Thanks, this looks great. I'll read through these and add this info in my next update. :)
20 karma · joined March 4, 2012
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?
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.
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.
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.
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.
> (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.
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 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.