> 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?
Hi Ryan, nice to see you're doing well (I remember you from High School).
MSVC's LTCG (LTO) pipeline has been heavily in use at Microsoft for decades now. PGO and LTCG go together. LTCG is the default way most of our binaries are built.
A lot of work has been done to make MSVC LTCG fast and scalable. In particular, the compiler backend is multithreaded on a per-function basis, and there is also support for incremental LTCG that reuses previously compiled machine code and summary information.
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.
Modern ART has a bit of everything, Assembly written interpreter for fast startup, followed by a JIT stage with PGO capabilities, followed by an AOT compiler that AOT compiles (with LTO) when the device is idle, and uploading PGO data into the Play Store, so that incrementally the same devices collaborate to the optimal PGO data set.
I'm not sure i would agree that the JVM and its ilk do LTO. They compile code to machine code at runtime, after loading the code it calls, and often after spending some time interpreting it. That means they can do interprocedural optimisations of the kind LTO can do (and then some). But they don't have the separate stages of compilation and linking that many ahead-of-time compiled languages do, which means they don't do linking, which surely means they can't do link-time optimisation!
This is incorrect. The JVM has an explicitly separate link phase [0]. The difference with AOT compilers is that linking is deferred until runtime. Rather than saying there's no link phase, you should think of it like as if your favorite AOT compiled language could support LTO on dlopen.
The linking mentioned there has nothing to do with the linking in LTO. It happens before JITting, and is neither a barrier to nor an opportunity for optimisation.
> 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.
Furthermore, those thousands of open issues hint to me that a lot of people are actively contributing, and that the dev team takes responsibility for legitimate problems.
Compare this to other projects with the illusion of quality because most bugs haven't been reported, or because their developers routinely dismiss and close reports of bugs that they don't feel like fixing, just to keep their bug tracker looking clean.
Indeed, the contents of the Matrix/Element/Synapse issue trackers played a significant part in convincing me that the developers are making good decisions, and that investing my time and contacts in this network would also be a good decision. That was over a year ago, and I do not regret it. The project still looks very much on track to me.
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.
I was kicked out of the future of coding chat group by Ivan Reese, who exercised his cancel culture powers to permanently ban someone for daring to say that Steve Jobs had cojones for ordering hundreds of millions of dollars in parts for his products before they even shipped and knew if people liked them, unlikes the cowards at HP who only bought 10k Idea Pads (which preceded the iPad). It is ridiculous to equate a colorful, and accurate, word "cojones" with a descent into madness. Steve Jobs by most personal accounts had a bad temper, but he was amazing, and I for one miss his great designs and inventions that he brought forth. To me, Steve Jobs is the most exciting inventor of my lifetime, an incredible example of masculine energy focused in a constructive and creative manner.
The community didn't vote on it, Ivan exercised his power, because has a personal dislike for me. I met a few nice people on that discord group, but didn't enjoy being followed around by word police.
I do remember this incident well. I guess each community has to decide how it wants to operate when people in that community feel disrespected and criticised. But I also remember this comment from Steve Jobs: https://greatresultsteambuilding.net/impact-teamwork-steve-j...
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...).
They're randomized to make it harder for an attacking program to find the location of it in a worst-case scenario when a Javascript or similar bug gives it read access to the local machine. The script in this scenario would be able to read files it knew the path of but not browse the drive properly. Without randomization, it would be a safe bet to try things like %USERPROFILE%\AppData\Mozilla\Firefox\Profile\Cookies and be able to pull your cookies for examination. If you can't get the USERPROFILE environment variable, the script could also do C:\Users\Admin\... and replace Admin with common names as well like John, Sue, etc. It also helps make it harder for malware to find. Not much harder, mind you, but it does require specific code to look for the Firefox profile as opposed to a single check.
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?