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

My totally uneducated guess is that they leak exaggerated numbers on purpose to make the real numbers look less bad in comparison. The idea being that a few days before the official news everyone is talking about a potential 30 or 40K people layoff. Then, when the official news come out and state that they are laying off 14K people, it sounds less dramatic (in relative terms). This makes people (who are not affected by this) to feel like the news were overblown and are not as significant.


Or it could have been internal politics. Amazon top management set the goal to cut 30k and after internal discussions with lower management they come up with 14k positions that can actually be cut.


Obviously not. Suppose the input to my function is a 64-bit integer. My test cannot possibly try every possible 64-bit integer. It would take years for such a test to finish.

This is why tools like formal verification and symbolic analyses can help you establish that for all possible integers X, your function does the right thing (for some definition of “right”). You get this assurance without having to actually enumerate all X.


Indeed. Exhaustively testing a 64b input space requires about 600 machine years for each nanosecond that the function under test takes to run. So, _very_ short-running critical functions are testable on a cluster, but not efficiently testable, and if a function is simple enough to be testable, then it's usually easier to prove that it's correct instead.


Very inefficient. Like wildly so. Specifically if you have a very small database and you preprocess it with their techniques, the resulting database is petabytes in size. But the results are very beautiful.

There are no obvious ways to improve on this work, so it is not a matter of engineering. We really do need another breakthrough result to get us closer to practicality.


This is strange to me. Many universities, including mine, avoid interviewing applicants with a PhD or postdoc from the same institution to which they are applying.


Being forced to upend your life and relocate far away every four years is also not a positive aspect of academic life.


You should try working for the State Department or the military!


Military officer corps at least comes with a insanely generous pay+benefits package when compared to PhD and post-doc. And the bar is lower and work easier for most positions.


You graduate, get an external, preferably foreign post-doc, and return to interview for the next available position. Problem solved.


At least in my department, this will not work as long as the applicant's supervisor or dissertation committee members are still in the department. The crux of the issue, in my mind, is that it is hard to have candid and unbiased discussion about a candidate when the supervisor / dissertation committee is part of that discussion.


This is basically what we did in our project: https://www.cis.upenn.edu/~sga001/papers/pung-osdi16.pdf.

We never built it into a product because we couldn't figure out a way to monetize it to pay for the servers.


From my experience your first number is off by 3X and sometimes more depending on the university.

But yes, you make less as a professor than you do in industry.


That definitely depends on the school. At my undergrad, tenure track CS faculty only got around 70k, going up to 90k over time. Lecturers got 55k. Adjuncts got paid more in exposure and good feelings than money. My grad school is a much bigger research school instead of a teaching school and the pay is surprisingly not much better (better, but not 180k until full professorship if ever from what I've found) from what I've heard.


For reference, at my uni (public) full tenured profs are making about $120k-$150k. Adjuncts are about $90k. Lecturers are around $70k. But that's in the CS department. Still, all of these people could be making at least double that in industry (some do double dip though).


They are called PIR with sublinear online computation or offline/online PIR.

Key idea is the client issues a query that is independent of what they really want. This is the “offline” query. This query is linear (unavoidable) and the client gets some hints as a result

Then later, the client can issue one or more queries for elements they want and those queries can be sublinear in terms of computation. The client uses hints to make that happen.

Some papers on this are:

https://eprint.iacr.org/2019/1075.pdf

https://eprint.iacr.org/2021/1438

https://eprint.iacr.org/2022/081.pdf


High risk compared to what? The alternative is absolutely no privacy (status quo) or no/limited functionality (not very useful). Seems like strictly better than having no privacy.


Depending on your compliance needs and the sensitivity of your data, "limited functionality" may be a reasonable tradeoff, though.


Using fake encryption is much riskier than no encryption, because if you think you are safe you will do unsafe things with your data. If you know you are unsafe then you will take appropriate precautions.


You can formally verify all the way to C, C#, Haskell, or even assembly if you use tools like Dafny, Coq, or Vale (for verified assembly). Several projects do this. It’s a lot of work for sure though.


Dafny is a really cool find, thank you!


Non interactive zero knowledge allows one proof to be checked by many verifiers. I think folks would still consider that to be a zero knowledge proof no?

That said, yeah this hashing example is not zero knowledge because, among other things, the hash is not hiding.


It's been a while since I read about zero-knowledge proofs, so I wasn't aware of the non-interactive kind. But I read up on them, and as I understand, you have to pre-commit to a finite set of participants in the protocol who can verify that you have the proof.

Which makes sense: If the evidence (that you have a mathematical proof) could be convincingly shared with absolutely everyone, it wouldn't be zero-knowledge any longer. The whole point of zero-knowledge proof is that the evidence is only useful for the recipient(s).


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

Search: