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

Also from the same author: Satellite Internet [0]

[0] https://tools.ietf.org/html/draft-omar-si-00


I'm lost for words. How does somebody get to the point of submitting a draft to the IETF, seemingly believing this is a new idea in 2017? Surely this must be trolling?

    "Each satellite holds routers connected to other routers on other satellites using fiber optic cables"
You'd need 265,000 km (164,600 miles) of fibre to loop around the geostationary arc!


Crank-o'meter goes to eleven!

But yeah, if it's this easy to submit drafts to IETF, how come they haven't drowned in spam already?



Well, the idea is obviously flawed, but I don't think the author meant geostationary orbits.


Then it's much more flawed if it's for anything but geostationary orbits. The way it's written it sounds like he doesn't understand that geostationary satellites have to be high up in the equatorial plane as he mentions each satellite having a specific area.


What.

Also, interesting snippet near the end of that draft: "Each satellite is connected to an earth station which is connected to the Internet core network on earth." He thinks there's a single "Internet core network" (http://tvtropes.org/pmwiki/pmwiki.php/Main/InternetIncorpora...)? No wonder he thinks it would be easy to forklift upgrade the whole Internet to his new protocol...


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.


The short answer is yes. There are some (slow) ways to fix this: https://people.csail.mit.edu/nickolai/papers/goldwasser-we.p...


Their construction relies on two unproven conjectures.

In particular the "Extractable Witness Encryption" conjecture is impossible under a reasonable falsifiable assumption: https://pdfs.semanticscholar.org/8587/dba4ff31e8118e9bd5914a...

Under that assumption, general purpose differing-inputs obfuscation cannot exist.

The way I understand it, FHE being applicable to anything other than "unwrapping a path through a circuit" seems implausible. Any claims of arbitrary encrypted computation should be viewed with the highest dose of skepticism.


Hmm so it doesn't work well with variable length data?


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.


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.


My point was "C with Classes" and "C with templates" versus modern C++ best practices.

C++ code can be quite safe, providing people stop writing C with C++ compilers.


Compile time is a pretty big reason.


so do you also not use std::unordered_map, std::shared_ptr, std::thread, std::regex, or std::mutex ? because they all come from boost.


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.


Once they're safely out of Boost and implemented by the stdlib they're an order of magnitude more convenient to use. You can also be more confident in their future stability.


> Once they're safely out of Boost and implemented by the stdlib they're an order of magnitude more convenient to use.

I don't understand this. Most of the time the API doesn't even change; you can just do `namespace lib = std` or `namespace lib = boost` according to which one you want to use. In my own code for instance I have a header where I choose the std::, std::experimental or boost:: version of `optional`, `string_view`, and `any` according to the recentness of the stdlib I'm using; nothing else is needed.


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)?


> How can a non-linear function even be convex in shape?

I'm not sure what you mean. Apart from the linear case (which is weakly convex), most convex functions are non-linear. So yes, it is not only possible, it is the norm (in a colloquial sense). Refer to this for a mathematical definition of convexity: https://en.wikipedia.org/wiki/Convex_function

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

There are two different cases:

1) Discontinuous functions: these are by definition nonconvex e.g. step functions. Gradient-descent methods cannot handle these directly; typically they are modeled as mixed-integer problems.

2) Non-smooth functions: are convex but do not have derivatives defined everywhere. e.g. abs(x). Gradient-descent methods don't work well on these types of functions. These typically require subgradient/bundle methods, or can be modeled as discontinuous functions.


yes, it's not smooth by definition

   d/dx √(x²) = x/√(x²)
because for x=0 the derivative is 0/0, but in this case it might be interpreted as the interval [-1,1]. That's just the way it is often plotted. I come up short with an algebraic explanation, it might as well be ]-∞,∞[ (deriving it from z(x,y)=1/y for example), but I imagine this as a bundle of tangents on the origin, parameterized by the interval. That's an infinitesimal curve, not just an infinitesimal slope if you will. So it's not linear algebra (I guess). The integral of the derivative is obviously defined everywhere, explain that. It's zero at zero, because the sum of the interval is zero. And if we are only interested in the boundaries of the interval at 0, than that's the tuple (-1,1). Just like complex numbers or vectors are tuples (but this isn't a complex number I guess).


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


Well, no, in this scenario, it is actually the function (in your words, the graph of the function) that is convex. A 2D example would be y = x^2 (a parabola), which is a convex function. A 3D example would be a paraboloid function, which is also a convex function.

The "volume" (or "area" in the 2D case) above the graph is called an epigraph.

One property of convex functions is that their epigraphs are convex sets (note the word "sets" this time). https://en.wikipedia.org/wiki/Epigraph_(mathematics)

Convex sets are more abstract in meaning, but in general in means can draw a straight-line between any two points in the region without going outside of the region.

Perhaps your notion of convexity comes from a mental idea of the shapes of convex and concave lenses? Those are good visualizations but in mathematics, convexity has a subtler, more rigorous meaning. With this rigorous meaning comes many nice mathematical properties that make optimizing them easier than nonconvex functions.


one definition of a convex function is that its epigraph

    { (x, y) : f(x) <= y }
is a convex set. Another is that the line segment between two points on the graph lies above the graph, i.e.

    (1 - t) f(x) + t f(y) >= f((1 - t) x + t y) for all 0 <= t <= 1
known as Jensen's inequality.

Convex function must be defined on a convex domain (no holes) and continuous at everywhere except the boundary of the domain.


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

Search: