whatidonteven

You could say that.

Every time you want to run a computation on your FHE-enabled VPS you would need to upload data proportional to the maximum number of operations in the computation. Otherwise, re-running the same computation with a different input gives away information about both of your inputs and about the computation.

Aren't there MASSIVE (read: showstopper) complications when you want to use FHE for "looping" computations?

I always thought FHE was only good if you can fully unroll your "fixed-length" computation, and even then you can only use each "program" once without compromising security.

There's a bit of a terminology confusion here. When they say "spinlock", most people mean a pure spinlock that spins forever until it succeeds.

"Mutex" on the other hand might have a fast-path that spins a few times before inserting the thread onto a wait list.

They are also the projects that get the most attention. I wouldn't rule out that python/javascript/whatever projects have just as many, if not even more, security flaws than your typical widely-used C library. They are just not interesting enough to warrant the required attention. The flaws are likely to be more subtle than simple buffer overflows too, think of all the abstractions involved.

I used boost extensively in the past (2006-2011). But I have been disillusioned by all the accidental complexity. It's easy to use the complicated parts of boost, but you lose sight of the inefficiencies you introduce all over the place, be it code bloat, unnecessary indirections, splitting up of allocations, or merely bloating your build times.

Besides, std::unordered_map is flawed, the bucket interface forces suboptimal cache behavior. std::thread is such a thin abstraction, if you use C++ you might as well use it but it doesn't buy you much. same with std::mutex. std::regex on the other hand I avoid because it's easy to write "regular" expressions that cause backtracking with it. I would look at something like re2 instead, if I had to deal with text parsing a lot. or a proper LALR parser generator if the language is not regular.

Ah, gotcha, so it's not the graph of the function that convexity refers to but the volume above the graph of the function.

Compile time is a pretty big reason.

How can a non-linear function even be convex in shape? I assume you mean the whole volume below or above the function and not just the function's surface itself?

Also, what about the case where the function isn't continuous or where it's not defined everywhere (the surface has holes)?