nhaehnle

Quantum computers don't really compute many things in parallel. Or rather, they do, but the problem is getting the results out.

To stick with your ray tracing question, you could probably indeed trace an exponentially (in the size of the computer) number of rays, but at the end you have to do go back to the classical world to actually read out data, and you'd essentially be able to only read out the result of one ray picked at random.

Quantum computers are only know to provide exponential speedups in cases where there is some algebraic structure to exploit when condensing the exponentially many computations down to a single result. That's why you can get an exponential speedup for factoring or discrete logarithm, but not for symmetric cryptography or really any other useful problem (except for the kind of circular problem of simulating quantum systems).

That's what makes me personally hope that quantum computers will never scale. The likely outcome of quantum computing is the worst of all worlds: all known practically useful cryptography will be broken, and practically nothing will really benefit.

There are many tools that come close (graphical GUI designers come to mind) by not actually giving you resulting code, but letting you write code separately that interfaces with the graphically designed parts in a well-defined way.

As both are 32-byte aligned, none of the uarch features mentioned in the article should be able to explain the difference. If anything, the baseline has the higher alignment (to 64 bytes), and yet the baseline is slower.

What you and the ggp are basically saying is that Intel slowed down the improvement in their processors on purpose over the last several years. Why on earth would they do that?

Besides, all the evidence points to the contrary, what with them being unable to compete in the mobile space.

At the same time, it's pretty well known that the kind of problem instances arising in practice and in those challenges are not hard instances. In other words, this also means that their result is extremely unlikely to be relevant for the P=?NP question.

Flatpak isn't about APIs. It's about making easy-to-use application bundles.

It's true that investment creates jobs, but it's also true that there's no investment without consumption.

The current prevailing economic policy consensus is very much misguided in that it only focuses on increasing investment. But investments just won't happen when there's nobody (or rather: not enough demand) to buy the resulting products.

This is why we need more policies that aim at consumption.

As a final thought: the reason why our prevailing economic policy consensus is misguided in the way it is is probably mostly down to motivated reasoning. If your goal is aiming at consumption, you have to look at the lower end of the income and wealth scale (because that's where the marginal propensity to consume is high). If your real goal is to make life even easier for the wealthy, it's comparatively easier to hide corresponding policies under the mantle of helping investment. Hence the focus on investment.

Skimming through it, it does seem pretty even-handed. Although I'd like to point out that you're writing a "guide for nerds" and consistently addressing the reader as if they were a man. Women can be nerds, too. It's fair to have a guide for male nerds, since the experience is bound to be quite different for men vs. women, but it'd make sense to actually point that out.

Things look different with margin trading though. Margin trading implicitly implies a loan from the exchange to the trader. If the market moves too much against the trader, exchanges typically automatically force their positions to be closed. The problem is that if the price moves too quickly, the proceeds from this transaction may not be enough to cover the loan to the trader. So then the trader can end up owing money to the exchange, and it may be difficult for the exchange to get that money. That can lead to solvency issues.

Maybe you don't call it GC, but doing a rebase in Git leaves the old, pre-rebase version around. That is a feature: over the years, it has happened to me more than once that I'd missed something when resolving complex conflicts during the rebase. Being able to refer back to the state from before the rebase was very helpful in these cases.

If Mercurial throws the old version away unconditionally, that would suck very much indeed.

If Mercurial keeps the old version, then perhaps at some point in the future I'd really rather have all that old data removed as a simple matter of saving disk space. Surely nobody wants to do that manually?

Hence: you either have a system that makes it much easier than Git to lose data, or you need garbage collection.

I don't know what Mercurial does, but somehow, the fact that this dilemma isn't obvious to you -- somebody who clearly seems to know a lot about Mercurial -- doesn't instill a lot of confidence in it.

Question: How does Mercurial deal with garbage collection? After all, the desire for garbage collection is by far not unique to Git -- any version control system that has the equivalent of `commit --amend` and rebase should provide it.

As for not needing the extension, it seems to me that having "dangling" commits would be very difficult to use without some decent visualization of the dangling commits, such as what the blog post shows with `hg show`.

> It's probably also worth noting that we have an implementation detail leaking into user space here.

I find this comment absolutely fascinating, because truly, this is not an implementation detail leak at all.

The point of the purely functional data structures isn't to achieve atomicity (although potentially being a bit more robust to power loss etc. is certainly a nice side effect), it's a way of thinking about version control. I've never heard functional programmers use atomicity as the main argument for immutable data structures, either...

The whole point of Git's design is that it chose a robust and crystal clear way of thinking about distributed versioning as its underlying model of what version control is, and then simply provided tools for manipulating that DAG. Some of those are a bit ugly because of how the system grew over time, but still, this is how software should be designed: have a clear model of what the data is, then provide tools for manipulating it.

For what it's worth, the underlying data store of Git could quite easily support "unnamed" tip commits as well. What you'd need is a change in the garbage collection policy, and "porcelain". Which brings me back to the question of how Mercurial does it.

Forcing a commit message is a good default, because it's a good idea to nudge developers towards properly expressing what they're doing. But if you think you know what you're doing, it's easy enough to work around.

(And, I might add, probably not by Hg either if it requires enabling an extension...)

Anyway, hg show work looks like an interesting thing. It's perhaps a bit more magic than Git usually goes for, since you can't just show all DAG sinks (it would get messy really quickly with amends and rebases). And I don't think I'd benefit too much from it, since I've come to prefer having all my work-in-progress on a single branch. But I can see how someone could appreciate the feature.

I recommend learning about the combination of `git gui` (including its amend option), `git rebase -i`, and `git commit --squash=/--fixup=` (and don't forget to set `git config --global rebase.autosquash true`).

The workflow in Git could still be improved: `git gui` should really allow you to create "squash!" commits more comfortably, for example (I often end up staging with `git gui` and committing on the command-line).

Also, it would be awesome to have an editor in which you could make edits to selected commits directly in a rebase-like fashion. But I don't think that exists for any version control system out there, and getting the UI right for dealing with conflicts would be quite challenging.

It's quite common to tell newcomers to always `git commit -a`, and `git add` for adding new files. That's pretty much exactly where SVN is/was, and nobody complained about that being complicated or onerous either.

There are also plausible-sounding arguments to be made in the opposite direction: Fractional reserve banking allows money to be created and destroyed adaptively to support the economy, which makes the economy run more smoothly overall.

That is indeed a large part of the point of the social/welfare state.

Many aspects of our societies have lottery-like qualities.

> The 'required for tax' purposes is a side-show.

Why can't it be both? :)

> Totally false. Inflation is a target by most central banks. They can make it positive or negative, generally, and target specifically 2% for certain reasons.

This is a bit questionable. There are good reasons why a slight positive rate of inflation is a good thing, and while you could try to target a negative rate, it would almost certainly be very harmful to the economy.

Basically, people and even many companies have fewer contracts or prices for selling things than for buying things. So when relative prices need to adjust, this adjustment happens more smoothly and faster when prices don't have to decrease in nominal terms (because e.g. an employee whose compensation should go down in real terms will fight very hard against a nominal decrease in their income, but will fight less hard against a broad nominal increase in their outlays).

So you should generally aim to have only very few (if any) items in your basket of goods whose prices are decreasing.

(Economists call this the zero lower bound and focus on salaries, but I'd expect the effect to apply to other prices as well.)

The arguments you've outlined are drawing a distinction between which kinds of property are thought to be just by certain schools of thought. However, this is entirely unrelated to the fact that all forms of property are coercive -- enforcing them ultimately requires (the threat of) violence.

Most people fail to make this distinction unless they properly think it through, though I personally find it most grating with the type of libertarian who argues with the "non-aggression principle" or variants thereof. I believe people make this mistake because it can be uncomfortable to admit to yourself that you're in favor of something that is coercive, even when the coercive thing is clearly a good thing overall. I'm sure there's a fancy name for this type of fallacy :)

... which isn't actually so bad when you think about it, as long as those BTC all went to their foundation.

Iota has bigger problems, like pretending to be more efficient by using a DAG, when in reality everybody still needs to see the whole tangle to verify transactions.

So apparently, transparent hugepages have some issues in their current implementation that can cause big performance losses in some cases. Seems to me like that's a bug, and I see no reason why that bug couldn't be fixed in the future.

By following random recommendations, you get into situations where the underlying problem has been fixed for ages, but people still cargo-cult some workaround that actually makes things worse with the new implementation.

How many people are there who are willing to use, say, 10k USD of their own money for gambling? How many greater fools?

Then again, some of those "greater fools" could be people holding Bitcoin that they collected from ICOs, so who knows.

As they say, the really tricky part of attempting to profit from the bursting of bubbles is the timing.

Your example of 100fps vs. 130fps on the same screen is inherently unsolvable in a proper way with anything less than a 1300fps display. So you have a bunch of tradeoffs, and I'm sorry to say that if the tradeoff you prefer is tearing, you're in the losing minority by far.

That said, if you truly wanted to write a tearing Wayland compositor, you could easily do so, and in any case plain X is still going to work as well.

Compositing is a good thing, and in the vast majority of cases its latency isn't actually intrinsically higher than writing directly to the front buffer. Certainly its intrinsic latency is never higher than writing directly to the front buffer if you build a system without visual artifacts. (Because at the end of the day, all compositing does is shift around who does the job of putting things on the front buffer; the jobs themselves stay the same for all practical purposes.)