Comments URL: https://news.ycombinator.com/item?id=49451549

Points: 4

# Comments: 0

The relevant regulations are Commission Delegated Regulation (EU) 2018/389 and the earlier Directive (EU) 2015/2366.

While these laws are deliberately vague when it comes to specific technologies, they do require at least two independent factors from different categories, such as knowledge (password) and possession (phone).

That, in and of itself, wouldn't be a problem. The way most banks implement it, however, is by giving you two choices:

1. You use their mobile app (which likely requires device attestation and Google Play Services, so won't work on a plain LineageOS install)

2. You use their CardTAN device, which is extremely inconvenient to always carry around.

Sure, we nerds might argue they should just let us use our Yubikeys or regular old TOTP, but pretty much no bank implements that. (Why? Your guess is as good as mine.)

Personally, I had to buy a second stock Samsung phone just for banking apps. And yes, there are still alternatives (only very very few though), but no, none of them are convenient, for various unrelated reasons.

I wouldn't be surprised if this continues to spread to the US too, under the sneaky disguise of "security".

crying in EU :(

Deficit spending causes inflation, and that type of inflation is a hidden, regressive form of taxation. It hits everybody, but the poorest suffer most when all the essentials get more expensive. The government creates new money, but really the value of that money comes out of everybody's income and bank accounts.

If additional government spending is truly necessary, it should be funded through transparent, progressive taxation, so that it only affects those who can afford to pay the tax, and so that the voting public is aware of it.

Unforunately, you're unlikely to win an election on the promise of raising taxes. The hidden tax of inflation, on the other hand, is so perfectly hidden in plain sight that most people don't notice it unless it gets out of hand.

Comments URL: https://news.ycombinator.com/item?id=47396575

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47386895

Points: 2

# Comments: 0

Otherwise, the only benefit more RAM gets you is better performance. But it's not like ZFS performs terribly with little RAM. It's just going to more closely reflect raw disk speed, similar to other filesystems that don't do much caching.

I've run ZFS on almost all my machines for years, some with only 512MiB of RAM. It's always been rock-solid. Is more RAM better? Sure. But it's absolutely not required. Don't choose a different file system just because you think it'll perform better with little RAM. It probably won't, except under very extreme circumstances.

Many developers, especially those in a rush, or juniors, or those coming from exception-based languages, tend to want to bubble errors up the call stack without much thought. But I think that's rarely the best approach. Errors should be handled deliberately, and those handlers should be tested. When a function has many ways in which it can fail, I take it as a sign to rethink the design. In almost every case, it's possible to simplify the logic to reduce potential failure modes, minimizing the burden of writing and testing error handling code and thus making the program more robust.

To summarize, in my experience, well-written code handles errors thoughtfully in a few distinct places. Explicit error handling does not have to be a burden. Special language features are not strictly necessary. But of course, it takes a lot of experience to know how to structure code in a way that makes error handling easy.

Comments URL: https://news.ycombinator.com/item?id=47127942

Points: 2

# Comments: 0

Now we just have to hope that standardization goes well. The C standard moves very slowly, and that's probably a good thing. But defer is such a simple yet powerful feature that the cost/benefit ratio should easily justify its inclusion.