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.

I refer to this as the "things I consider important/am passionate about" capitalization style, which happens to be popular in Government.

I've done a similar thing with Scala in the past - ship the compiler jar and then compile your configuration (which is just an abstract class implementation) as part of the startup process.

It's actually relatively easy to be sodium deficient if you are physically active (as you shed sodium via sweat) and don't eat processed foods regardless of whether or not you are vegetarian. In my case the only significant source of sodium other than the salt shaker is cheese.

It's a hard problem, NHibernate actually came a little bit closer with it's QueryOver API. The most glaring problem with the LINQ API is there is no way to OR two reusable conditions together because the only tool you have is Where.

To be clear you can get a long way by abusing EF's willingness to try and interpret arbitrarily complex expressions - it just provides zero tooling or guidance on how to build those expressions.

Or projections. It's possible to write a reusable projection for EF like so:

    class MyTableProjection {
      public static Expression<Func<MyTable, MyTableProjection>> Expression =>
        t => new MyTableProjection {
       Id = t.Id,
       Str = t.Str,
       Flag = t.Flag
     };
    
      public int Id { get; init; }
      public string Str { get; init; }
      public bool Flag { get; init; }
    }
    
    dbContext.MyTable
    .Where(...)
    .Select(MyProjection.Expression)
    .ToListAsync()
    

But I have never seen anyone do this because it breaks the promise that you magically won't have to write any code or abstractions.

There are three problems than an ORM should solve to some degree:

1. Type safety/refactorability

2. Composability (can I reuse my queries)

3. Expressivity (can I generate the queries I want)

Of these, EF only solves the first, which is far and away the easiest of the three.

Composability in EF is possible via expression tree splicing, however it requires such a degree of discipline and insight that I have never seen anyone do it, or even any discussion around it.

Like almost everything in the .NET ecosystem, EF makes a bunch of promises that are fantastic for hello world, but are disastrous as your project grows.

Scala doesn't really have a name for this, it simply permits you to provide a block in lieu of a parenthesized argument list. Given that blocks are expressions:

    val a = { val x = 2; x + 1 }

the syntax you are describing is just a function-valued block.

To quote James Mickens, "large swathes of the security community are fixated on avant-garde horrors such as the fact that, during solar eclipses, pacemakers can be remotely controlled with a garage door opener and a Pringles can."

The challenge is that the validator sets the rules for who is vaccinated.

As an example, some jurisdictions might declare individuals with single doses protected.

Another real example: the EU is unwilling to accept Covishield vaccinations, despite it being AstraZeneca/Vaxzevria manufactured in India.

Rent control does keep rent low. What it creates is a supply problem, which could possibly explain the decades-long wait list for an apartment in Stockholm.

People keep bringing this up, and the question you need to ask is why would anyone other than miners choose the non-fork chain? The fork will happen as long as one person is willing to mine it.

No, because it depends on the executioner's intention.

Implicits haven't been removed, they've just shuffled the keywords around to appease the 'implicit bad' crowd. Type classes are an incredibly important language feature, and implicit parameters are a generalization of the required functionality.

I would argue that under both proof of stake and mining your income is always directly proportional to the amount invested, either in equipment or stake.

The main difference is the minimum barrier to entry, however under PoS you have access to various pooling services, which simulate consumer scale mining (complete with the associated inefficiency).

Open membership is arguably a worse problem than stake requirements, as PoW participants do not have a vested interest in preserving the integrity of the chain. Ethereum 2 actually throttles validator entries and exits for exactly this reason.

As an example, any sufficiently powerful entity can temporarily and affordably commandeer computational resources with the intention of disrupting the chain.

Under PoS doing so would devalue your (presumably enormous) stake, so participants are at least incentivized to act in the interest of the chain.

This is the last thing I'd be worried about. It's coffee, not some kind of anabolic steroid/cocaine mixture.

I know a lot of people who spend way too much time trying to optimize supplements and other tiny details instead of throwing down and getting on with your life.

Edit: after reading other comments yours makes more sense, but I'd still be more worried about what's actually in a pre-work out beverage than over-exertion.