Hacker Newsnew | past | comments | ask | show | jobs | submit | stelfer's commentslogin

It goes deeper than Little's Law. Every decent textbook on introductory queuing theory has the result that on a normalized basis, fast server > multi-server > multi-queue. That analysis admits almost arbitrary levels of depth of analysis and still holds true.

Your observation that computing architectures have chased fast server for decades is apt. There's a truism in computing that those who build systems are doomed to relearn the lessons of the early ages of networks, whether they studied them in school or not. But kudos to whoever went through the exercise again.


To me it sounds like they hacked the editor/code signing tools to insert malicious code on save/commit by devs. Having iron-clad CI toolchains don't help you with that. Need to focus on how to defend the devs.


That's the point of a trusted build farm. Devs commit changes to git, and either request a build or the build farm polls for commits and builds the latest commit on trusted hardware+toolchain.

A malicious attack could change the code but it would be detectable because git would preserve the malicious parts in the repo, and further tie a specific malicious binary to a particular commit making it easy to find the malicious code itself.

As long as not all developers are compromised then whoever is doing the code review would see the malicious code when they pull the branch to review it.


> further tie a specific malicious binary to a particular commit

Git uses SHA1 for hashes, right? Aren't there demonstrations that SHA1 hashing is cracked, so you could craft a replacement commit that hashed to the same value, in theory.


The developers of git are working on moving git to use SHA2 and have already mitigated some of the concerns around using SHA1: https://git-scm.com/docs/hash-function-transition/

SHA1 hash collisions are hard, especially when the data you can inject needs to look like code to a human and compile correctly. But the concern is valid so it's good that git is improving in this way.


Based on the description, the source code wasn't modified, only the build tooling on the developer machines. As such a CI server wouldn't be impacted.


> So how do we guard against this type of attack?

Looks like they compromised the editor. If so, then I imagine checking checksums for each component of the toolchain would work. Though if they compromised the filesystem or runtime then that would complicate things. But still, a hash tree or certificate of the OS and toolchain as part of CI would seem to be a good idea in 2021.


The act of measurement on the second particle destroys the entagled state of the pair. That effect can be measured on the first particle's side (which may be far away... on the other side of the galaxy maybe).


But to see/interpret the effect on the first particle, you need to know what the measurement on the second was, and that information needs to be transferred across the galaxy by conventional means.

Honesty quantum mechanics sounds more like a bug in the universe or some quirk we just don’t understand yet.


> effective, accessible

because they all run as root

> , and easy to use

yeah


It's a strong statement but it definitely leaves the door open. Given that there's so much at stake I can't imagine a different statement.

On the other hand, if you read the CISA alert[1], it's clear that (1) many industrial targets were compromised, given the ubiquity of the Orion product and the amount of time that transpired; and (2) the attackers had their merry f'ing way with MS products like AD. So at this point I think it would be more surprising if they were not compromised than if they were.

[1]https://us-cert.cisa.gov/ncas/alerts/aa20-352a


Are you saying that the attacker's skill with AD indicates that they were able to plant code in AD? Steal the source and learn vulnerabilities from it? Or just that, given that MS uses AD, they were vulnerable too?


Take a look at Google Private Join and Compute[1]. But be aware that the problem you frame is an unsolved research problem with an active global community. The topics you are looking for are applications of secure multiparty computation and homomorphic encryption. Also, be ready for something as simple as a column join to take 24 hours per query.

[1] https://github.com/Google/private-join-and-compute


Probably never. Unique in the Crowd: The privacy bounds of human mobility[1].

[1]https://www.nature.com/articles/srep01376


True, but OTOH CA will likely start to change it's forestry management practices as a result of this. The distribution of surface fuel is a joint effect of drought and policy/management.


Why do you say likely? I would have said that after the Camp Fire and I would have been wrong.


The less forest that there is left after the fire, the easier it is to clear the rest and replant with tree species that are better at holding onto water in drought conditions, and/or species that are hardier in the face of heat exposure.


The native trees in CA are types that need forest fires for the next generation of seeds to grow. Obviously there are many different trees with different ways to breeding, but we would lose biodiversity if CA followed your plan.

What CA needs to proper forest management, which means different things to different parts of the state. Often parts of that mean regular prescribed burns (which courts have historically stopped - lesson learned: shoot smokey the bear...)


You're assuming that the reward function is giving you the community you want. In reality the reward function is to maximize engagement, which is a proxy for ad revenue. When there's an asymmetry in engagement dynamics then the whole thing drifts. The mass fallacy here is that FB is trying to build communities.


The "engagement" that you're talking about is causing other people to leave, so I don't know how that works in FB's advantage here.

If they really wanted to maximize "engagement" they would actually hide all of the political posts and rage inducing comments and show nothing but cat pictures.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: