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?

You should checkout Shaarli[0] that has a thriving community.

[0] https://github.com/shaarli/Shaarli/

Isn't the phrasing "density of space" a bit off? I mean a density is a scalar quantity of something per unit of space. So Density of Space would literally mean quantity of space per unit of space?

Reading the article it would make much more sense to say: Density of Matter in Space Outside of the Solar System.

The difference with a colorizing, cleanup or restauration effort of a material object is that in that case the source material is not destroyed.

In that regard, the only downside for historians is that it might become more difficult to find the source material if upgraded versions of it proliferate, but this is not like rewriting or erasing history like some have claimed.

The new Slack on mobile is absolutely unusable. There are no way to know if the interface is up to date, when was the last update or to force an update.

The only way I found to know that your message has been received is to have an ack from your interlocutor.

Not OP, but one good reason to do that is to reduce probability and frequency of collision with other periodically running jobs.

Let's say you run your job on the hour, and you have a job running every 4h and another every 24h, without planning, because 4 divides 24, you have one in four chance of having them collide and having the 24h job running at the same time than the 4h job. If you add more 4h jobs, the probability that one of those 4h jobs collide each time with the 24h job increases.

The more jobs you have, the higher the probability that some will be divisors of others.

Using prime number for scheduling reduce the probability at a given time that those jobs collides. If you create a job every 5h and another every 23h, the 23h will collide with the 5h job every 115h. PPCM(5, 23) = 115.

Interestingly, this technique is used in nature by cicadas who developed long, prime-numbered, periodical life cycles to avoid gaining a predator that can sync up with the cicadas[0].

[0] https://www.cicadamania.com/cicadas/cicadas-and-prime-number...

Existing discussion: https://news.ycombinator.com/item?id=24488224

One factor that is missing from this post is the processing time on the backend which is also insanely fast. This post only considers frond-end optimizations.

On the author's benchmark, a roundtrip seems to take on average 30ms, and the time to first byte for the main content is around 140ms. Which means that in less than 110ms Google is able to parse the search query, and build the HTTP response.

I'm sure they are heavily relying on caches and other optimizations, and for tail-end requests the result might not be as impressive. But compared to many other websites in 2020 this is still unfortunately not the norm.

I know nothing about GP, but note that it is possible that English is not his first language, and the subtleties of the story and vocabulary might be lost in translation.

In my native language (French), as you describe it, there is no word for "average" (the technical and the common terms "moyenne" are exactly the same). Until your comment, in English, I assumed you could use "average" and "mean" interchangeably.