CptMauli

over 200 comments and not one mention of Threema, come on!

And this is exactly why that report is somewhat misleading. On the cheaper end of cars, a lot of those are not maintained regularly, and this is the reason why they fail in the first place. And if you look closely, in most cases the reason for the fail has something to do with lights or brakes or tires. Stuff which does not cost much to fix in a Dacia, but is crazy expensive on the upper end, BMW etc.

I had the first major issue with my Dacia since I bought it 7 years ago, and it had something to do with the LPG installation, and it was about 1000€. From a TCO standpoint of view, that car is so dirt cheap, only my little Seat Mii (CNG) - which I bought used, is cheaper.

A bit of a strange article. Of course they are right that VW is struggeling. But to suggest to only favour tech monopolist solutions is from a strategic standpoint a really bad idea.

And it is very surprising that nowhere in the article is mentioned that VW - in comparison to other auto makers - at least, has a plan. They specifically bundled all the software operation into a new company, CARIAD. If that will work is a different question.

It's pretty simple, they are all bad, aren't they?

Especially all the network configuration variants went from bad to worse over the time.

I think its not fair to put the Elbphilharmonie in the same category.

The original plan looked very different from what was later realized. Which was a significant driver of the cost.

Just for fun, lets compare it to the Sydney opera house:

Elbphilharmonie, original projected cost: 186 Mio EUR

Elbphilharmonie, final cost: 866 Mio EUR

So in the end, 4.65x the projected cost and 7 years late.

Sydney Opera house, original projected cost (inflation adjusted cost in parens): 7 Mio AUD (70 Mio EUR)

Sydney Opera house, final cost: 102 Mio AUD (632 Mio EUR)

So in the end: 9-14x the projected cost and 10 years late (depending on if you compare based on the inflation adjusted costs).

Therefore, in comparison, not that dissimilar.

Since the number of dependencies is way less then in the JS world, its possible to pin them down manually.

If you absolutely need to have multiple versions of the same dependency, you probably need to use OSGi.

The point is, that in a moderately complex Java project that might be something on the order of 150-200 dependencies, and updating just one of those usually doesn't lead to a big change in the transitive dependencies (it is a different thing for a major update, Java 8 -> 11, or from the pre jakarta JEE to jakarta), but its possible for a single person to track whats happened. But with 1500+ dependencies, so an order of magnitude bigger, its just not possible.

Even then the cost of utility scale solar and wind was not that much higher than it is now.

I still think plus is fine in this case. And really, my expectation is, that anybody who thinks about adding a months, knows about their own intention. Because I suspect just adding the month is not what most people are actually doing, I guess in 90% of the cases most developers will add another step, rounding to the last (or first) day, or to the next same weekday, whatever.

The one thing nobody wants, is to add a month and land in the month one over.

So even if the semantic differs between libraries for adding a month, it actually doesn't mather that much. Because for all the other cases one could imagine, most people will add days or weeks, if staying on the same day matters.

Just because the air isn't prewarmed in his original setup, it doesn't mean its no heat pump.

It was reported about it in the German press. I'm an opponent of nuclear power, but in this case I can only shrug and conclude that everything worked as expected, the issue was identified and dealt with.