I'm not sure why people struggle with the fact that an abstraction can be built on top of a non-deterministic and stochastic system. Many such abstractions already exist in the world we live.
Take sending a packet over a noisy, low SNR cell network. A high number of packets may be lost. This doesn't prevent me, as a software developer, from building an abstraction on top of a "mostly-reliable" TCP connection to deliver my website.
There are times when the service doesn't work, particularly when the packet loss rate is too high. I can still incorporate these failures into my mental model of the abstraction (e.g through TIMEOUTs, CONN_ERRs…).
Much of engineering and reliability history revolves around building mathematical models on top of an unpredictable world. We are far from solving this problem with LLMs, but this doesn't prevent me from thinking of LLMs as a new level of abstraction that can edit and transform code.
Both those questions are answered clearly in the readme:
> compared to avante
> I think it's fairly similar. However, magenta.nvim is written in typescript and uses the sdks to implement streaming, which I think makes it more stable. I think the main advantage is the architecture is very clean so it should be easy to extend the functionality. Between typescript, sdks and the architecture, I think my velocity is pretty high. I haven't used avante in a while so I'm not sure how close I got feature-wise, but it should be fairly close, and only after a couple of weeks of development time.
And:
> Another thing that's probably glaringly missing is model selection and customization of keymappings, etc...
Without knowing exactly how createNewGroup and addFileToGroup are implemented it is hard to tell, but it looks like the code snippet has a bug where the last group created is never pushed to groups variable.
I'm surprised this "senior developer AI reviewer" did not caught this bug...
Hosting some services on a vps provides far better availability of data, than doing it at home. Especially when you need it the most. For example when you are moving to a new home, and need to save documents, or you are abroad, need a document and there is a power outage at home.
Even if you have to trust a 3rd party with your data, (1) you can minimize the privacy risk with encryption and (2) usually VPS/cloud providers have different privacy guaranties than free Google drive...
It is interesting because SMART being "niche jargon term" is very dependent of the audience. Nowhere the author needs to assume that the post will be posted on HN where the audience is probably larger than the originally intended one.
In many places NixOS is a niche jargon term.
Also, in the first paragraph of the article there is a direct link to smartd that has a clear explanation for what smart is, no need to Google.
Note that this law has only been voted by the Senate, and not the "Assemblée nationale". For a law to be adopted in France it must be voted in both chambers. And the "Assemblée nationale" has much more political power.
On the flip side, the amount of materials, metals, and energy necessary to produce enough batteries to replace current fossil fuel usages, are order of magnitude larger than the current world production and known reserves.
This presentation does ballpark analysis of the problem:
The most important git feature I discovered was `git add -p`, this allows both to select which patchs to stage, but also to do a review of what you are going to stage. Combined with `git commit -v`, this allows you to have plenty of occasions to review your changes before creating your pull request.
The title seems a it of an exaggeration, here is what is in the article:
> In a Monday morning blog post focused on its headquarters near Seattle, Chris Capossela, an executive, said that starting Feb. 28, “employees will have 30 days to make adjustments to their routines and adopt the working preferences they’ve agreed upon with their managers.”
I'd like to apologize if this sounded judgmental. English is not my main language, and perhaps my phrasing sounded like I assumed my domain specific opinion is better than the actual people working on the the project.
Reading the other comments, and maybe to contextualize to my question better, I'm more surprised by how the project is presented as marvelous to the public, rather than thinking that any technical part were overlooked.
While I'm sure that engineering teams at NASA and ESA have countless contingency plans, procedures and failure models. Medias around the project seem to focus on how fragile the deployment procedure is. Great engineering is an act of finding the best balance between opposing constrains, by building technically sound systems but also more importantly designing robust human or automated procedures.
In this story, in my opinion, the media presents a skewed explanation of why the project is incredible by highlighting that it would be incredible that such a brittle deployment procedure would even work.
I do have a question about JWST that I wasn't able to find a fine answer in other forums.
A lot of people and engineers are saying that the JWST is a marvel of engineering, with truly inovative technical solutions and a giant step up compared to Hubble Telescope. And it does seems like so!
However, I'm always baffled how everyone seems proud that the telescope has something like 200 SPOF during deployment, and if even one of them fails the whole mission could fail.
I know that each step has probably been throughoutly tested, and that the acceptable probability of failure of each one of those steps has been deemed acceptable. But I'm still surprised that people are proudly conflating excellent engineering with a design that has a large number of spofs.
In my domain this would be considered as a terrible design (aka "hope is not a strategy"), even given the constraints of mass and volume that such project incur: 200 hundred low probability events, chained, can get in the realm of possible.
I can't imagine JSWT team doing "bad engineering", so I'm sure I'm missing a piece. Is it only PR that underline this aspect? Is JWST as brittle as the news want to make us think? Or are there technical reasons or acceptable failure modes that gives confidence that those steps are not as critical as the news let us people know?
In the Facebook bug listed in the post this specific mitigation would probably not have been enough since the bug was due to invalid instructions emitted by the JIT.
Under exact same workloads, two duplicate JIT running on two duplicate CPU would have most likely emitted the same erroneous code.
Take sending a packet over a noisy, low SNR cell network. A high number of packets may be lost. This doesn't prevent me, as a software developer, from building an abstraction on top of a "mostly-reliable" TCP connection to deliver my website.
There are times when the service doesn't work, particularly when the packet loss rate is too high. I can still incorporate these failures into my mental model of the abstraction (e.g through TIMEOUTs, CONN_ERRs…).
Much of engineering and reliability history revolves around building mathematical models on top of an unpredictable world. We are far from solving this problem with LLMs, but this doesn't prevent me from thinking of LLMs as a new level of abstraction that can edit and transform code.