voidmain

I'm a bit amused by the advice to move to SF because that's what all the other nonconformists are doing.

"Cyber insurance" may reimburse the site operator for the liability they have to you for (say) being infested with malware. And that model seems to work OK for car accidents. But I think that only helps you (the site visitor) if you already have a practical ability to sue the site operator (particularly difficult if the site operator is on the other side of the globe, in a jurisdiction you know nothing about). What I'm proposing is that the insurance company offers to accept direct liability to site visitors, with well defined liquidated damages and arbitration processes so that it actually means something to the user.

If someone is offering that today, they aren't marketing it well. And again, actually signing the certificates would be a negligible part of the business (or the cost).

Actually, if I were in the insurance business I'd actually think about pushing this direction. If you could get the browsers to sign up for giving it special treatment it would probably greatly increase the size of the market. (Right now operators seem to mostly just escape significant liability for compromises)

I have no idea what I'm talking about, but if you have a control flow translation pass that is intended to translate constructs like goto and produces "uglier" code, why not automatically disable it for functions (or whatever granularity works) with no such constructs?

To give an example, in a 2016 interview Sanders referred to open borders as a "right-wing" "Koch brothers proposal". Trump is worse, is that what you want to hear?

I'm not trying to draw a moral equivalence. But I think the barriers to immigration raised over the last century and more everywhere in the first world are something that can't be blamed on any single party or political movement.

If you want to know if a site is trustworthy, you want a certificate from their insurance company, not their CA. Someone who is promising to pay you real money if the site contains malware or a scam or whatever. Unfortunately this sort of insurance would probably be more, not less, expensive than EV certs.

I'm not going to tell you that there won't be problems caused by increased migration. Anything that changes the world so much will cause problems. I'm not going to tell you that America's material wealth is the result of "random chance", either. But I do think that quite a lot of it is the result of centuries of immigration, each wave of which was met with much the same objections.

It's one thing to caution against removing all barriers literally overnight. I don't know that it would be a disaster, but I don't know for sure that it wouldn't, and it's reasonable to exercise some caution. But, at the risk of making an inflammatory analogy, it would have been morally defensible to ask if there was a way to end chattel slavery in the US without a civil war that killed ~3% of the population. It was not morally defensible to oppose ending it. Global apartheid is an evil of a similar scale, and first world governments its active cause, not innocent bystanders. It is our duty to figure out how, not whether, to end it.

I can't prove that there is no limit to how many migrants the first world could absorb without losing the rule of law, but it's pretty obvious that if there is such a limit it's higher than the status quo!

It's not exactly hard to find anecdotal evidence. For example, Haitian households living in the US had a 2015 median income of $47,200. I don't know exactly how to translate this into per capita terms, but Haiti has a per capita GDP of something like $730. I'm sure that these groups of people are not perfectly comparable in every way, but it's certainly suggestive that people can make a better life for themselves here than in Haiti. How do you think you would fare in Haiti?

If you want a more rigorous extrapolation, which tries to account for confounding factors and isn't limited to one pair of countries... you are going to have to look at the research (of economists).

I haven't read his book. But Borjas, who is to be clear a bit of an outlier among economists who have studied the problem, has in the papers I've looked at estimated that immigration is (slightly) a net economic negative for the very least skilled workers in the first world. This is nowhere close to saying that the net economic effect of immigration, including the benefits to the immigrants, is negative.

If people could migrate freely around the world to seek work, economists crudely estimate that world GDP would roughly double, and that most of this enormous windfall would go to the poorest people on Earth. There is literally a hundred trillion dollar bill on the sidewalk for bringing together third-world labor and first-world legal systems, capital, and service demand.

Instead the first world does its best to wall itself off from economic migrants, because the right fears that migration will threaten their culture and the left fears that migration will threaten the welfare state.

As with any prohibition, the economic opportunity gets colonized by criminals. People seeking a better life will be taken advantage of and some of them will even wind up worse off than they started. But the root problem isn't the criminals, and it isn't customers who want cheap electronics. It's the prohibition of migration.

No, "exponentially faster" means exponentially faster with exponentially more hardware. Specifically, N processors can solve a problem of size N in O(log N) wall clock time, where the previous (serial) algorithm used O(N) wall clock time. Most programmers would say "more scalable" or "more parallel" rather than "faster", but the terminology makes sense and is standard in the context of the PRAM model of parallel computation.

I'm not sure, but I doubt this algorithm is "faster" than the previous one on a single processor.

(The article is drivel; I couldn't figure out what they were talking about either, until I looked at the paper)

The model [1] GP alludes to claims that competition forces small governments to provide better (more efficient, more optimally chosen, etc) local services than monopoly governments, for the same reasons that competitive companies are expected to provide better services at a lower price.

[1] https://en.wikipedia.org/wiki/Tiebout_model

In this case, as I understand it, they also disabled the emergency braking feature built into the Volvo. Which wouldn't be obviously crazy if they had better, adequately tested emergency braking integrated with the "autonomy" system. But to disable the existing safety feature in favor of their own system, and also disable their own system due to a high false positive rate, seems negligent on the face of it.

One day, through the primeval wood, A calf walked home, as good calves should...

[1] http://holyjoe.org/poetry/foss3.htm

Deterministic code cannot receive a side channel. It may, as you point out, be able to transmit on a side channel. It might even be able to "reflect" one side channel into another one. But these risks seem both less severe and more easily mitigated. At least, the history of attacks of the latter types is not very impressive.

I'm familiar with this narrative, I'm saying that the evidence in the article, though the article is written by someone sympathetic to this point of view, contradicts it. The PE firms, despite their huge fees, lost a boatload of money. No one wanted to buy the business out of bankruptcy for more than it was worth piecemeal. There are easily identifiable reasons (Walmart, Amazon) why the competitive landscape is much tougher than when it was a profitable business. It sounds to me like the PE firms did a lot of harm by keeping the company from bankruptcy for so long.

In general, if a business is clearly profitable it should continue no matter how thoroughly you screw up the capital structure: the worst case is a bankruptcy in which the shareholders get nothing, the debt holders get very little, and a new capital structure gets created. When this doesn't happen, it's because the business is worthless or nearly so.

Despite the title and the focus on the form of financing, none of the facts in the article even suggested to me that the company would be in any better shape if it had used equity financing rather than debt. It sounds, rather, like an unprofitable business that no one in their right mind would give any more money.

If someone thinks they can figure out how to make a workable business out of big box toy stores, it sounds like the name is for sale.

That isn't how tax deductions work. Even very tax efficient giving will not save you $1.00 of taxes when you give $1.00!

I think they mean digging up coal and burying it in the ground again. Carbon captured, mission accomplished!

> like breathing

When you eat 1kg of peanut butter, if I've done my math right, you'll breathe out about 2.3kg of CO2. Dry cereal would be about 1.5kg. Most foods have a lot of water in them, though.

Determinism is related to purity ("functional programming"), but is a weaker notion. For example, this function

    var c = 0
    function deterministic_not_pure() {
        return c++
    }

is not pure, and you can't reason over it equationally. But it is deterministic: if I make a series of calls to this function in my browser, and you make the same series of calls in your browser, and someone else emulates the code using a Turing machine made of rocks in the desert [1] we will all see the same results. (And consequently, there is nothing that such code can do to learn about its environment!)

As far as I know everything in Javascript-the-language has this property! [2] (Equally, so does WebAssembly). And most of the browser's APIs do as well, though the sheer size of that surface means that any attempt to fix the rare cracks will still be daunting. The vast majority of information that browser JS gets is either through events (i.e. function arguments) and I think most of the rest could be safely forced to be deterministic during the execution of a JS function.

It's still obviously possible for these events to leak timing information about the execution of JS, but I think that can be fought. For example, you could delay the delivery of every event by the number of nanoseconds that JS has executed on the page so far, though of course that naive approach will gradually degrade in performance. But I think for example doing that until you have 10ms of delay and then resetting would probably make timing attacks totally impractical.

All of this needs way more thought, and I'm not at all suggesting that it's easy. But browser JS is closer to an actually-securable-against-side-channels state than almost any other widely deployed platform, and I think it's sad for the people that control the platform (which is, let's face it, basically the Chrome team) to throw it away because they love performance.now() and SharedArrayBuffer.

[1] https://xkcd.com/505/

[2] Well, ECMAScript probably doesn't specify a random number generator, for example. But it could.

> We don’t believe it’s possible to eliminate, coarsen, or jitter all explicit and implicit clocks in the Open Web Platform (OWP) in a way that is sufficient to fully resolve Spectre.

I'm not sure, but I think they are giving up on the best strategy here. The holy grail is for untrusted code to be totally deterministic, so that it cannot exploit Spectre or any other side channel attack.

Browser Javascript, which is historically single-threaded and event driven, is much closer to this than native code ecosystems where there are decades of investment in shared memory multithreading (which is very hard to make deterministic!) I don't think it would be impossible to make a JS engine where any given Javascript event handler and all the synchronous APIs it can call are deterministic, so that all interaction with the nondeterministic outside world is through events (and the "outgoing" side of these interactions would be delayed until the event handler stops running). Then I think you could make it so that the runtime of JS isn't measurable, or at least is only extremely coarsely measurable, via these events.

Well, if with your best technology you can pack B bits of information in 1 m^3 of space, and you need to store N bits of information, you are going to need (N/B) m^3 of space to store it. And then the speed of light limits you to around (N/B)^(1/3)/c seconds of latency to get to the farthest bits.

(This ultimately violates the Bekenstein bound - as your server cube grows it will eventually collapse into a black hole - but this is not really a concern with forseeable technology! More practically, though, Earth's gravity makes it hard to build very high in the air, which limits you to O(N^1/2), and things like cooling and maintenance access probably impose a limit somewhere in between.)

The increasing latency [1] of access to larger amounts of storage isn't a constant factor, though, even asymptotically. There was a fun post on HN a while ago arguing that random access latency to N bytes is asymptotically O(N^0.5), from both empirical data about real systems and theoretically from the Bekenstein bound and the speed of light. And even if you don't buy that it clearly can't be less than O(N^1/3). Don't go preaching this in job interviews, though :-)

The truth is that complexity theory is always done relative to some abstract machine model, and as with all models it's up to you to determine if the model is a good fit for your practical reality. "To the extent that mathematics reflects reality it is not certain, and to the extent that it is certain it does not reflect reality." There exist abstract models, like the cache oblivious model, that do a somewhat better job of grappling with this issue but don't require to just throw up your hands and rely solely on benchmarks of real hardware. There is probably room for new theory in this area.

[1] not throughput, which isn't as hard to scale up

> any application can be made correctly with READ COMMITTED isolation if required set of "mutexes" and their acquire/release is correctly implemented

This is true, but it's "a big if." And the result might be faster than a good implementation of serializable isolation (since the latter is working to maintain some invariants that you don't actually care about), but it could easily be much slower: very broad invariants will require very broad locks which cause much more "serialization" than is required for serializability.

Let's say you want the same sum invariant but across rows: all users' balances must sum to zero. The straightforward application of your reduction is to essentially have a global mutex for all balance transactions, but this is nowhere near the most scalable solution. Whereas a good serializable database will handle this situation scalably, safely, and automatically.

> it is enough to verify only that each transaction writing to any of those fields is also writing to that "sum" field and that it does uphold the invariant

This is a good try at a theory of when you can use weak isolation. But as stated, I believe it is false. If the invariant is A+B=C, I think this sequence is permitted by READ COMMITTED:

T1: read A=1

T2: read B=1

T2: write A=2

T2: write C=3

T2: commit

T1: write B=10

T1: write C=11

T1: commit

Now A=2, B=10, C=11

More to the point, invariants aren't always local to a row, and people don't usually even fully articulate them.

> There is no need to pay the huge performance price of serializing those transactions with all the rest of transactions in the system

Serializable execution can be made very very fast when there aren't actually a lot of conflicts. And then when there are you can do the hard work of trying to prove that something weaker will work. The failure mode in the other direction is silent corruption of your data.

I've always wished for this in every communication medium.

Charging someone for calling you would also block them permanently, so almost no one is going to do this to their friends just to mess with them. There should be no appeal: if someone wants to charge every caller, that's totally fine. People will stop calling them pretty fast. Likewise I would let the callee choose the charity, or even keep the money. All that matters is that if you are calling someone who wants your calls you won't be charged, and if you aren't, you should be. If you aren't sure, you pay your money and take your chances that you are in fact imposing on someone else.

I can't see how this would hurt anyone of any socio economic level other than spammers. If you are calling someone who doesn't want your calls, you are a spammer.

It looks to me like the original gradient based shading code is just wrong. Maybe there are numerical problems due to its frivolous use of trig functions, or more likely the way it calculates gradients is just broken. But shading based on slope should obviously make all zero slope areas (like water) the same color, and the fact that it doesn't means it isn't working.

The raycasting code in this article, on the other hand, seems to be missing the Lambert term! Just because a surface is not in shadow doesn't mean that it will appear at uniform brightness. If it is diffuse/matte, which seems like a reasonable starting point for most terrain, each light ray L should have a contribution to the brightness of the point proportional to L dot N, where N is the normal vector of the surface (and to find that you need, sorry, the gradient). In short, light almost tangent to the surface doesn't illuminate it much. Other kinds of surfaces will have different BRDFs (e.g. they can be shiny) but none of them will have the completely unshaded behavior shown. Of course, it's fine to do totally nonphysical things if it helps emphasize some aspect of the data, but it doesn't seem to be done knowingly and I think it produces a misleadingly flat look.

Yes, I agree, the article's approach will definitely win for small tables. But readers of this article may want to solve the same problem on big tables, so should be aware that there's an asymptotically faster solution.

(Actually, I think you could probably use the article's approach in combination with DFA techniques to build something that's both fast and scalable. Something like a finite state automaton doing something like what's in the article at each node. But I don't need this and am not going to invest in trying to figure it out or learn whether there is prior art.)

There is an asymptotic speedup available for this problem, to the extent that there are lots of prefixes in the table: a finite state automaton representing the regular expression ^(prefix1|prefix2|prefix3|...) can be matched against a length N string in O(N) time, regardless of how many prefixes are in the regex. This approach is also behind the Aho-Corasick algorithm, which I think finds all occurrences of the strings but could be easily modified to find only prefixes.

I don't know if, in practice, the constant factor speedup in the article would beat out this asymptotic advantage for the table sizes that matter to the author. But the article doesn't mention considering and rejecting this approach.