There's no free alternatives, because AMD doesn't document the bitstream format (i.e. what you need to push to the FPGA to program it to do wha you want).
Xilinx has the best silicon. Everyone else is behind. Altera is basically dead thanks Intel. Lattice is nice for low power but performance-wise they are behind. Don't know much about Microchip, but from the little I've heard their tooling is a disaster even by the standards of FPGA tooling. Then there are Gowin (not bad, but Chinglish docs and everything), Gatemate (pretty innovative and vendor-backed nextpnr support - but only one low-mid FPGA with a promise to release chiplet assemblies of it latter). And Effinix - don't know much about them, do anyone have experience?
It's not. There's a duopoly between AMD (Xilinx) and Intel (Altera). There's more choice at the very low end but if you're going for a powerful FPGA (which is mostly what people need) those are the choices.
I too guess they meant Red Hat. But that move just resulted in really big clients switching to RHEL derivatives like Rocky or Almalinux. Closing systemd would spawn a fork and possibly an specification effort for non-systemd components to join in.
Technically, all adult Catholics can become Pope. But realistically it's just one of the cardinals, which means you need to become a bishop first, which means you need to become a priest first, which means you need to be celibate (x). This guy has a wife, according to the article, so he cannot become a Pope.
(x) this is technically not true for some Anglican orders that later became Catholics? Maybe? (I never remember the rules of the ordinariate.) So maybe he could first become a priest in Anglican Church, then switch to Catholicism, then become a bishop, then a Cardinal, then a Pope? It's a long shot though.
edit: ahhh the married priests in Ordinariate cannot become bishops. So he would need to have first his marriage annulled I guess.
While this is for practical purposes true _now_, there actually were a small number of married popes (https://en.wikipedia.org/wiki/List_of_sexually_active_popes#...), and there have been a few popes who were not priests before being elected (if you want to be pedantic, Peter wasn't a priest, and may have been married, but there were later examples).
> all adult Catholics can become Pope
All adult male Catholics, though also see Pope Joan (probably didn't actually exist, but was generally believed to have existed until quite recently). There's also no actual age requirement, though in practice the youngest pope was _probably_ 18.
Catholic Church's records on early popes are often surprisingly bad, particularly in antipope-heavy eras. There are a _number_ of popes where the detail is pretty vague. Use of damnatio memoriae also confuses the issue, eg: https://en.wikipedia.org/wiki/Pope_Formosus#Legacy
eh not really, we NOW have quite good records on most popes except for the first few ones that we get just in a list from St Irenaeus (for example from St Linus - the guy immediately after St Peter - we get almost nothing)
but about the middle age popes we know quite a lot NOW. But it used to be different.
Sure, anyone and everyone can apply, to basically anything. Sometimes you can even get into stuff they didn't think they accepted applicants to. Most of the times you get ignored though.
I would guess these plugins are chosen so a majority of user won't want to live without them.
It also seems these plugins "link" to canvas-lms, so keeping the proprietary would be a GPL violation if anyone except Instructure holds part of the copyright to Canvas.
I got tired of dealing with SSH knocks and blocked the port for all external IPs, using WireGuard to get into the LAN.
WireGuard is nice because, unlike most other services, it operates on UDP and sends no reply packet unless you know the key, so attackers can't discover it by portscanning.
I find that a very bold move, how will they reivent the wheel on the man-years of optimization work went into LLVM to their own compiler infrastructure?
Proebsting's Law: Compiler Advances Double Computing Power Every 18 Years
You need to implement very few optimizations to get the vast majority of compiler improvements.
Many of the papers about this suggest that we would be better off focusing on making quality of life improvements for the programmer (like better debugger integration) rather than abstruse and esoteric compiler optimizations that make understanding the generated code increasingly difficult.
No, the whole point is to eliminate dependencies that they have to maintain. "not obligate" really doesn't mean anything if it's available as a backend--the obligation is on the Zig developers to keep it working, and they want to eliminate that obligation.
And the original question was "how will they reivent the wheel on the man-years of optimization work went into LLVM to their own compiler infrastructure?" -- the answer is that Andrew naively believes that they can recreate comparable optimization.
There are a whole lot of misstatements about Zig and other matters in the comments here by people who don't have much knowledge about what they are talking about--much of the discussion of using low-level vs high-level languages for writing compilers is nonsense. And one person wrote of "Zig and D" as if those languages are comparable, when D is at least as high level as C++, which it was intended to replace.
First I was naive to believe I could make a new programming language, then I was naive to believe it would be anything but a toy project, then I was naive to believe that we could make our own backends for debug mode, now I'm naive to believe that we can add optimizations to the pipeline. It's getting old. Just because you lack the creativity, willpower, and work ethic to accomplish something, doesn't mean I do.
I admire your creativity, willpower, and work ethic, and a few other things about you, but I don't admire reactionary garbage like this ... I'm actually rather shocked by it and how it leans heavily on the strawman "I'm naive to believe that we can add optimizations to the pipeline" which is not the statement that was made, but I will maintain my high regard for you and your efforts despite it ... no human is perfect. I have a lengthy list of technical brilliancies in Zig that I admire that I won't bore you with but do often bore others with.
At least you acknowledge that I am correct about your belief, whereas someone else said I was exactly wrong.
As for me, while I had a successful software development career spanning 6 decades, received a mention in a two-digit RFC, and hold several networking patents, my best years are far behind me, but even in my heyday I couldn't hold a candle to your creativity, willpower, work ethic, or productivity ... but how is that at all relevant?
And that is grossly dishonest ... my original comment said nothing about what is true for me, and I never assumed (or assume) that what is true of me is true of others. In fact the whole point of my comment that you are responding to here is that I don't think that what is true of me is true of you--you are clearly better at these things than I. You are just being pointlessly and ungraciously belligerent. It's a hell of a way to treat consumers and admirers.
> zsf team is perfectly capable of implementing compiler optimizations.
Again with that strawman. The issue was about duplicating the years of effort put into LLVM. No doubt with ENOUGH effort that can be duplicated--logic dictates that ... but then it has to be continuously tracked. And when I said "recreate comparable", there is of course an implied time scale.
You're all in a huff because I used the word "naive". But then you made an argument that your naivety gets the damn thing done anyway because of will power, work ethic, etc. I grant that it's a good argument with results to prove it.
Enough ... I won't be provoked into responding again.
I think you are overestimating the impact of the long tail of compiler optimizations. You don't need to reverse-engineer every microarchitecture under the sun and optimize for their specific quirks like LLVM does to have useful code generation.
Just doing the basics goes a long way with a tiny fraction of the effort. Yes it will leave some percent on the table but this is hardly the end of the world. With their own compiler they have full control over the entire chain and might be able to make up for that with their own language-specific optimizations.
Go has a custom compiler, too, it's not as good as LLVM, so what?
To clarify, my statement was based on comments I have seen and heard from Andrew Kelley when discussing this subject. I can't locate those at the moment, but here is https://news.ycombinator.com/item?id=39156426 by mlugg, a primary member of the Zig development team (emphasis added):
"To be clear, we aren't saying it will be easy to reach LLVM's optimization capabilities. That's a very long-term plan, and one which will unfold over a number of years. The ability to use LLVM is probably never going away, because there might always be some things it handles better than Zig's own code generation. However, trying to get there seems a worthy goal; at the very least, we can get our self-hosted codegen backends to a point where they perform relatively well in Debug mode without sacrificing debuggability."
The current interim plan (which I think was developed after the comments that I heard from Andrew, perhaps in recognition of their naivete) is for Zig to generate LLVM binary files that can be passed to a separate LLVM instance as part of the build process. Is that "a first-class supported backend target for compilation"? I suppose it's a matter of semantics, but that certainly won't be the current LLVM backend that does LLVM API calls.
What do you mean by "interim"? As I explicitly stated in the comment you quoted, it has never, and likely will never, been planned for the Zig compiler to become incapable of using LLVM. The LLVM backend still sees plenty of active development by the core team [0]---that's perfectly compatible with improving the experience of users (including ourselves) by avoiding unnecessary uses of LLVM [1].
> ...is for Zig to generate LLVM binary files that can be passed to a separate LLVM instance as part of the build process. Is that "a first-class supported backend target for compilation"? I suppose it's a matter of semantics, but that certainly won't be the current LLVM backend that does LLVM API calls.
I think you are incorrectly assuming that we currently make heavy use of the LLVM API. As indicated by #13265 being closed, that is not true. The Zig compiler already generates bitcode by itself, without touching the LLVM API. The only thing we actually use the LLVM API for is feeding that bitcode to LLVM, which can easily be done by invoking a CLI instead. Users quite literally would not be able to tell if, for instance, we changed the compiler to pass the bitcode to Zig's embedded build of Clang over CLI.
> the answer is that Andrew naively believes that they can recreate comparable optimization.
That's exactly wrong.
> There are a whole lot of misstatements about Zig and other matters in the comments here by people who don't have much knowledge about what they are talking about.
as a comment about a particular project and its goals and timelines, this is fine. as a general statement that we should never revisit things its pretty offensive. llvm makes a lot of assumptions about the structure of your code and the way its manipulated. if I were working on a language today I would try my best to avoid it. the back ends are where most of the value is and why I might be tempted to use it.
we should really happy that language evolution has started again. language monoculture was really dreary and unproductive.
20 years ago you would be called insane for throwing away all the man-years of optimization baked into oracle, and I guess postgres or mysql if you were being low rent. and look where we are today, thousands of people can build databases.
reply