dimtion

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.

> Mythos is “far ahead of any other AI model in cyber capabilities.”

Yet not far ahead enough to prevent the data leak.

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...

With huge blobs of binary model weights, dynamic linking is cool again.

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...

Or, businesses could do like they do in Europe: set the same price after taxes in every state.

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.

It is called the Brussels Effect[0]

Put simply, given how large the EU market is, and how strong its regulation is, it is cheaper for companies to comply, even outside of the market.

[0]: https://en.wikipedia.org/wiki/Brussels_effect

Given your last sentence incidental complexity can be created and destroyed (and is more difficult to destroy than create).

The quote would probably be more accurate as:

> "ESSENTIAL Complexity can neither be created nor destroyed, only moved somewhere else."

We are starting to get there: https://viper.cs.columbia.edu/

Note that this is from October 2021.

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.

In short nothing has been decided yet.

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:

https://youtu.be/MBVmnKuBocc

Even if the numbers are off by an order of magnitude, them problem remains worrisome and difficult to solve at scale.

Amazon WFH policy is still flexible though. For example, in my team the current policy is to work wherever we feel the most productive and happiest.

You could have potentially moved within the company if that was only decision factor.

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.

Shameless plug, but here are other efficiency tips I wrote about, for working in a high demanding environment: https://dimtion.fr/blog/average-engineer-tips/

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.

The UI issues you are mentioning are very minor and have been like that in Telegram for years. I would say that there are different way to present a feature and coming from Whatsapp you are used to one way of doing things.

IMHO Telegram has the best UI and UX of all other "family friendly" chat app.

I do agree on the Voice and Video calls that need more improvement.

Do you happen to know where to find any resources on how Apple managed to make the M1 so good compared to the competition?

And why this has not happened before with other manufacturers?