melolife

I had this issue and it appears to be fixed in the latest version of mutter available for Arch.

I was going to say "as opposed to a little less than an hour's walk", but in the US there is the question of how many 14-lane highways and Costco parking lots you would need to cross during that hour.

I've seen bad service design having e.g.

Before=systemd-user-sessions.service

This means that as long as systemd is trying to (re)start the service, nobody can log in. Which is a problem with infinite restarts.

It's still pretty easy to accidentally set up an infinite restart loop with the default settings if your service takes more than 2s to crash.

The general argument is that if you are a proto-government/warlord/gangster, you want to encourage/coerce your subjects into agriculture as the output is easily taxed and stored. This turns out to be wildly successful for creating large hierarchical societies, which in turn forces their neighbors to do the same to survive.

Unlikely. The new collection literal syntax exists as the dual of the pattern matching syntax, which itself exists primarily because you can't reference a generic type by name without specifying the type parameters.

If you want to write out Dictionary<Guid, ILookup<int, List<MyEntity>>> instead of having it inferred then go for it I guess.

After some more experimentation it looks like you don't support allOf/anyOf/oneOf which seems like a pretty big hole.

I'm interested in new offerings in this area, as all of the existing options are pretty janky. A couple of thoughts:

Operation.summary is typically derived from the documentation for an API operation, and should not be used as the operation title as it is far too long. Instead use the operationId and path.

I can't get it to render schemas for a bunch of my OpenAPI documents, and there are no error messages to guide me. Does this handle recursive schemas (which can never be fully expanded)?

Collection literals are a pointless extension of the pattern matching syntax added to get around the fact that there is no way to name a generic type in C# without specifying its type arguments.

It's yet another double down on object initializers instead of writing constructors and factories, and unlike using a factory you have to fully express the result type of the collection instead of having it inferred (they are "target typed", another feature that probably should not have been added).

Edit: see TheK's answer, which is virtually identical.

So there are two problems as I see it:

Firstly you see analyses like these where the author goes "see, heat pumps work fine in cold climates, look at these success stories!", and then proceeds to list a bunch of places that aren't particularly cold. People think Norway is cold, but if you look at Wikipedia then the average daily low for Tromso (a random northerly Norgewian municipality) in January is -5.6C, with a record low of -18C. Compare this with Calgary, a relatively southerly prairie city with an average low of -13.2C and a record low of -44C.

The second problem is that they say "don't worry, if it actually gets cold it switches to resistive heat!" The problem here is that the extremes absolutely matter, because this is when demand is highest. If a prairie province/state switches everyone to heat pumps, then your grid had better actually be designed for everyone to be using resistive heat for weeks at a time, because that's exactly what's going to happen when you need it most.

They really can't because of the ventilation requirements and the amount of water vapor produced.

It's interesting that 9000 is the starting port for Ethereum consensus clients, although the participation rate does not seem to be affected.

You'd have to be trying really hard (read: on roids) to be anywhere near a situation where adding muscle or cutting fat makes you less attractive.

Ignoring the fact that XMLHttpRequest is a hideously unlovely API, it's a huge problem when your primary asynchronous abstraction is not implemented by your primary API for async IO.