SparklingCotton

I've used lens for years and years, but don't fully grok it. Who cares? Lens is also like category theory, you don't need to understand the details in order to use it.

Well of course they are using some sort of "lint" system and they know the reason.

Why not give the information to the user? There is no need to use any manual labor here.

I'm in exactly the same situation. It's impossible to know what they are after and my extension has a fraction of the permissions that you have.

Many good reasons why this would work in Europe.

- Logistics in Germany is awesome, and Amazon really doesn't have a leg up on the already existing logistics solutions there.

- For a cloud provider, negotiating deals now when AMD is on the rise must be perfect.

- Beating AWS on EC2 pricing is easy. AWS EC2 pricing is insanely expensive. German providers like Hetzner Cloud entered the market at 1/10th of the EC2 price.

- A k8s-focused cloud provider gets an enormous number of already existing k8s services without the need to compete directly with all the AWS services.

A "Hetzner Cloud" + K8S in Germany? I'd move all my stuff there.

Then at least make it free for off-peak hours.

In a simple tax system there aren't that many deductions. This is especially true for low-tax jurisdictions.

If you want non-standard deductions, create a company and do normal accounting.

50-100 standard deductions can be handled centrally by the IRS with no issues. It's been done in other countries for decades.

Chile has both lower taxes and automatic taxation.

In 2019 they will even have automatic taxation for small businesses based on the statistical average for the industry and various signals.

So basically taxation based on machine learning.

You can take it or leave it - it's up to you.

And this also shows that simpler taxation and higher taxation has no relation to each other.

But even within a region, having corporations do private deals with the government is corrpution.

You are not supposed to be able to get special privileges to your company to the detriment of your competitors.

There can be no free market when justice (and thus taxation) is not blind.

Amazing how your single data point lead you to that conclusion..

Apple should be forced to pay back 10x what they gained in this illegal deal.

It's bleedingly obvious that it's illegal to be taxed differently than other companies. Paying back €13bn is nothing.

Companies that "make deals" on tax anywhere in the world should be effectively banned from the EU market. It's pure evil. Or pay 10x of any gain they have made anywhere in the world by "making deals" on tax, thereby undercutting fair competition in a free market.

It should have been obvious to Apple that they were receiving illegal subsidies, given that they were taxed differently than other companies.

"The Irish government agreed a deal with Apple in 1991 to only tax a certain bracket of its earnings" http://uk.businessinsider.com/how-apple-managed-to-get-its-t...

To me it's pretty obvious that Tim Cook will burn in hell :-).

While it's certainly Apple's prerogative to play EU states off against each other to get the best deal

It certainly IS NOT. When Apple "get's a deal" it is by definition market manipulation. You're not supposed to "get a deal" regarding taxation!

The same taxation rules must apply to every company or else there is illegal subsidy. The whole idea around "making a deal" on tax is horrendous anti-capitalist BS.

It's exactly the same as "making a deal" wrt the law in a corrupt country. A corporation "making a deal" by having government look away when they do something illegal, or getting their competitors fined on dubious charges.

Apple, Google, Microsoft, and basically all of those companies ARE THE SCUM OF THE EARTH for not refusing do to business with the market-corrupting Irish Republic.

Since the EU wants Google to stop within 90 days, I assume they can give them a fresh €4.5bn fine if they refuse. At least that's something.

That's a good reason why fines (like what Google is getting) should be huge.

It's deliberate to kill competition while not being in a dominant position, and then when in a dominant position, continue the trajectory by defining defaults.

The Apple apps are dominant partially because of the abusive rules the app store had earlier. It's quite clear from the fact that in any area where Apple did not have a default app, they are unable to match what the free market offers.

But what you can do as a user is not really relevant.

I cannot change the defaults in an Android phone and sell it to you. That's the problem.

I don't see this reasoning at all. The fine is because Google is illegally cementing it's position as a dominant search engine through licensing of the android platform.

Where is the problem with making Android free?

Yes Google (if that's what you mean by Android) does "block" having Bing as the pre-installed search engine.

Monopolies are not illegal, so your argument is irrelevant.

If the EU wants to preserve any credibility ..

It's the other way around. EU is building credibility that seems to be lacking elsewhere by penalizing anti-competitive behavior.

Then why did you call your variables x and y, and not y and x? Surprise: because there IS a semantic meaning to the order.

The haskell variable naming convention is bad. What is worse is that when someone points it out, there is ALWAYS this one or two variable example being put forward, when the problem exists in the 90% of functions that have 5 or more variables in scope.

I see a lot of haskell code that looks like FORTRAN. Haskell code is yet not written in large companies where there is a readability requirement. I just hope more programmers with a better taste for readability joins the Haskell ranks. The readability story needs to improve (and I see it improving a bit..)

But "real memory" is neither what C presents or the copy semantics that is used in FP.

The CPU will keep memory in 64-byte cache lines. There is a complex bus protocol to shuffle cache lines and subparts of cache lines to main memory.

There are additional complex protocols for cache coherence.

The cost of reading 64 bytes from memory into a cache line and when doing a write-back, storing it at a different location in main memory is zero.

Memory is always being copied into our L1 and L2 cache.

Copying data eliminates most of the cache coherence protocols that are complex and costly.

Yes we get a lot of this for free in the CPU implementation, but there is a lot of complexity that goes into imposing what is really beginning to be an unnatural model (mutable memory) on a hierarchical memory system.

FP is using a log-based model. You write to fresh memory, no aliasing, no coherence, no conflicts. You then, during GC, remap memory.

Current hardware cant "remap memory" efficiently, but it seems like the FP approach, in one form or another, is the better approach for dealing with high scalability and deep memory hierarchies: write to fresh memory, then expose a remap operation at the hardware level.

SSD disks are a bit like that internally.

No it simply does not, because the language forces you to write pure functions. The type system invites you to express invariants.

There are very fundamental connections between strong typing, program verification, and proofs.

http://en.wikipedia.org/wiki/Curry-Howard_correspondence

Thus, the argument that Haskell probably has the same, is simply false.

There are large web platforms in Haskell. Yesod is probably the largest eco-system. It is clearly not as well used as RoR, but anyone can dig through large amounts of code to try to find these bugs.

What Haskell has that everyone else has are bugs/misunderstandings in how protocols are implemented. Sometimes there can be fundamental bugs in the run-time-system. However, large classes of bugs are fundamentally less likely to appear than in less safe languages.

What you say can easily be disproved, and you are simply asking for too much if you ask for something to be a drop-in replacement for OpenSSL. Some re-architecting is requred simply because of the insecurity of C.

For example, a shared library that implements SSL would have to be a shim for something living in a separate process space.

http://hackage.haskell.org/package/tls

That is a Haskell implementation of TLS. It is written in a language that has very strong guarantees about mutation, and a very powerful type system which can express complex invariants.

Yes, crypto primitives must be written in a low level language. C is not low level enough to write crypto, neither securely nor fast, so that's not an argument in its favor.

There is a "just use X". If you code in a language where you can express the invariants in your code, and make the compiler check those invariants, then your code is immune to all of the vulnerabilities that we have seen in OpenSSL.

The fact that these languages don't automatically do all my system administration tasks for me is not an argument against using them.

http://en.wikipedia.org/wiki/Nirvana_fallacy#Perfect_solutio...

C and AsmJS are just as open to side channel attacks. AsmJS is safe, C is unsafe.

I'd take javascript over C any day.

What are the efficient ways of preventing this kind of bug, if not type systems?

The parent had a good point and you should really try to look at Haskell before you say that kind of nonsense.

All the tools that are available for static analysis are basically extra type systems bolted on top of existing languages.

If you try to detect buffer overflows using static analysis of the linux kernel what you need to do is to is go through the source code and define invariants. Those invariants are TYPES in languages powerful enough to express them.

For example the invariant that memory, or any resource allocated must be freed can be expressed in Haskell.

In C++ it cannot be expressed. There are workarounds like RAII, but that does not give any guarantees.

If you do not think type systems and thus languages make any differences, you also cannot believe that formal verification makes any difference, because type systems are a weak form of formal verification. How "weak" depends on the language.

You should also read up on the Curry-Howard correspondence to learn something about the deep connections between types, programs, and proofs.

http://en.wikipedia.org/wiki/Curry-Howard_correspondence