pushrax

It takes >12h to build Windows on the MS build platform.

On a single core, Chromium surely takes hours to build.

Though I agree that 40min for the repository in question is highly suspect.

I am fairly sure it uses thin packs during a clone usually. Though I checked the docs at https://www.git-scm.com/docs/shallow, and it says:

> There are some unfinished ends of the whole shallow business:

> - maybe we have to force non-thin packs when fetching into a shallow repo (ATM they are forced non-thin).

Also worth noting that git is pretty efficient at cloning a bunch of subsequent commits, due to delta encoding.

edit: looks like git doesn't implement fetching thin packs when populating a shallow clone. It will still avoid fetching unnecessary packs, so the efficiency is still high for most software repositories.

Also, profiling applications is surprisingly easy to learn. It boils down to looking at timestamps, and seeing what takes the longest. The majority of the effort is just figuring out where/how to get the timestamps you are looking for.

I will add that I think software complexity is only going to continue increasing over the long term; it reduces in some domains, but expands in others as we develop more advanced systems. Some kind of analogy to entropy.

I would expect that internally someone profiled the build (i.e. looked at timestamps) and then either profiled git, or just looked at the logs and did some guessing/research. This didn't seem like it would be complicated to find once you realize the time is spent in git.

Also, this probably has been an exponentially increasing problem, and wasn't really a priority to solve until relatively recently. I would bet there are a lot of stale undeleted branches.

This is one of the best Wikipedia entries I have read yet. Concise and relatively plain English. Clear description of benefits, shortcomings, and possible tests.

I would guess it’s similar to the chunking they do when streaming in the first place. Assembling the pieces is one of the main functions of youtube-dl.

You can debate whether "leverage" comes from the noun or verb form of "lever" (which both exist, and the "-age" pattern is used for both nouns and verbs), but the main point is that "leverage" used as a verb breaks prior usage of "-age" in exactly the way I described.

"leverage" has been used as a noun for centuries, but as a verb for only decades. It's a recent neologism.

TIL about x-client-data. It looks even worse than user-agent, it's completely unique per user.

I think you mean user-agent rather than referer?

"leverage" used as a verb bugs me the most. The "-age" suffix is clearly established as a way to form a noun, in this case with the base verb "lever".

If we treat "leverage" as a verb, "leverageage" is valid.

In the end price discovery is supply/demand, and it appears investment in DRAM manufacturing is focused on improving RAM performance, and just keeping up with demand, not outpacing it.

Since the barrier to entry is very high, there's not so much pressure to compete further on price.

Yep, the main idea is to set up the liquid interpreter with the right variables/methods and the right liquid templates, and evaluate the result. There’s a lot of code that runs around that, but the path-specific code is quite small.

Hello :)

Differing inputs causing verification failures is indeed an issue. In addition to data access races, replication latency also causes this. The legacy service always reads from the primary MySQL instances per shard, but the new service always reads from replicas for scalability and geo distribution.

One slightly helpful mitigation we have in place relies on a data versioning system meant for cache invalidation. The version is incremented after data changes (with debouncing). To reduce false negatives, we throw out verification requests where the two systems saw different data versions. It's far from perfect, but it's been effective enough.

“Not a CRUD app” isn’t a design decision, it’s just that storefront is almost entirely read-only, and the views are merchant-provided Liquid code. Most of a shop's data can be accessed on any page; data dependencies are in large part defined by the view, not the controller.

(contributor here)

The project does still use code from Rails. Some parts of ActiveSupport in particular are really not worth rewriting, it works fine and has a lot of investment already.

The MVC part of Rails is not used for this project, because the storefront of Shopify works in a very different way than a CRUD app, and doesn’t benefit nearly as much. Custom code is a lot smaller and easier to understand and optimize. Outside of storefront, Shopify still benefits a lot from Rails MVC.

I’ll also add that storefront serves a majority of requests made to Shopify but it’s a surprisingly tiny fraction of the actual code.

None of those things are necessary to consider something a process.

These are the ways the strategies differ:

- a token can be invalidated individually, while resetting a password invalidates all sessions

- a token can be given a predetermined expiry without the issues that arise from predetermined password expiry

- a token can be given a limited permission set

- a token can be used to track the origin and extent of an attack

In practise for something like TeamViewer I find it likely that none of these except the first would be implemented. If the attacker has access to the registry chances are you're f*cked anyway.

Exactly. Hence posing the question (rhetorically, I suppose).

How does WASM fill this gap?

> fast compiles, fast startup and fast runtime ... mainstream

C is this but it's harder to write secure/correct C, the standard library is smaller, and there's no canonical toolchain in the same way as Go.

Aside from the cases you mentioned, there are other dynamic languages in which numbers are by default floating point. e.g. Lua. I agree though.

It appears you did not see the critical point in the above comment. "Performing arithmetic operations against money in floating point is the dangerous part, as error can accumulate beyond an atomic unit."

Storing money in floating point is fine. Just round to the nearest atomic unit when displaying. Sometimes this is a necessity when working with money in e.g. existing JSON APIs. You lose a few bits of range relative to fixed point storage but it's almost never a practical issue.

Performing arithmetic operations against money in floating point is the dangerous part, as error can accumulate beyond an atomic unit.

It’s interesting to take this view and apply it to personal identity. A self seems to be a low fidelity model of one’s autonomous system.

It seems necessary to include a model of self to reach the kind of predictive ability necessary to learn from few examples.

Attempting to appeal to everyone by serving a different ad based on tracking is precisely what I meant, but I'm thinking more from a platform standpoint than as a brand. An ideal marketplace would prefer to sell a spot to brands who advertise in a way that appeals to the buyer.

This is true with encrypted credentials, if security is compromised by release of the repo then the encryption is not secure. I think the spirit of the principle is met, and in cases where you do later release the source code without having planned for it, it's easy enough to move the secrets.

It's definitely more convenient to use the same repo, especially in the declarative containerized world; you can make sweeping changes or roll them back in a single atomic commit.

That said, if open source is the intent, certainly use multiple repos from the beginning so you avoid git gardening when releasing later.

i.e. you want to see the facets you'd be looking for when choosing a product to purchase.

For many products and people that will just be the visual appeal, and advertisers target their widest audience.

This is a case where tracking can actually be seen in a positive light - I too think I would be more likely to convert if I saw a datasheet as an ad, but that's definitely not majority. At the same time, obviously fashion ads will convert better as images, in almost everyone.

Config also benefits from review and version control, and it's inconvenient to use multiple systems for these. It's been working out well for us to store secrets encrypted with public key crypto alongside source, or in a deployment repository using the same source control. The private key is inserted into the infrastructure as a K8s secret.

Mind linking the patchset?

On the other hand, if you don't want to open pdfs by accident, use "Always Ask" .. https://support.mozilla.org/en-US/kb/disable-built-pdf-viewe...

It really depends on your domain. If you're into low level hacking and distributed systems, there is a lot more algorithmic work. There is demand for software that's cheap to scale and/or low latency. Some fields are bottlenecked by hardware (machine learning, realtime rendering, etc.) and so benefit from better software. Some production systems still need a large amount of optimization to satisfy economic and product constraints.

I don't think the number of jobs requiring fairly deep systems or algorithmic knowledge has gone down, but the ratio has.