bipson

h266 would be pointless for your problem.

There is something for you to understand here:

CPU/GPU "intensiveness" of a codec depends, and an increased computational overhead of newer codecs is always to be expected. The more efficient a coded (perceived "quality" per bit), the more complicated the computations of decoding need to be.

That's why most (consumer) CPUs built in the last decade have hardware decoding support (having a dedicated hardware implementation is always more efficient than running on the CPU) - and often even hardware encoding support.

The difference between h26x decoders must not need even that big (depending on the implementation). Widespread use of h264 killed most notebooks because of the missing hardware decoder.

h266 would with 99% guarantee never run more efficient on the same hardware than h265, unless we find some magic to achieve better-then-h264 encoding with MPEG1 complexity, and if this was easy, why was h265 not that.

And then there is AV1, which makes any newer MPEG-LA standard pointless anyway. You just need to wait for the respective widespread use of the hardware en-/decoders (and efficient encoder implementations I guess).

Why adding the last paragraph, in particular the first sentence of it?

Although I can't prove the sentence incorrect as such, it is stated in such a vague and alarmist way, that it could easily taken as an example of fueling the FUD?

Yes, and those vaccines were pulled.

Once a vaccine has shown to be just remotely as dangerous as the illness it is trying to prevent, it becomes pointless and is no longer available. The respective regulative bodies in either country are rather strict about which vaccine is allowed to circulate.

The point here is the limitation "apparently".

Huge part of the needless discussion about the risks of vaccines happening in well educated parts of the population are misattributed effects of vaccines.

Everyone I know apparently knows someone that has a child that has a serious condition because of a vaccination. Yeah, right, if it was so clear cut and widespread, these vaccines would be pulled from the market yesterday.

Yes, according to the manufacturer of one of my cars, idling the cold eninge should be avoided - considerate driving quickly after starting the cold engine should be considered instead.

The argumentation in the manual is that the car won't reach operational temperatures for a longer time while idling. New efficient motors apparently idle very efficiently (surprise?), which generates not enough heat.

Wait, that makes no sense in the context of the above argument.

For the windows to fog up, you need to sit in the car right? How long do you need to sit in your car until they fog up? Why are you sitting in your non-moving car for so long? And how often does that happen?

In our cars it takes about 10 minutes in cold winter before the fog comes up when around 2 people sit in it, unless it is raining and we just jumped in wet a minute ago. And it's gone a minute after starting the AC again. And one is a small car 2 week short of being 20 years old.

From this viewpoint I cannot possibly understand your reasoning? Are you trying to find an excuse to disable Start/Stop?

Not everyone. It is a very small minority where I live.

I don't even see people letting their cars idle while scraping, which was the norm 15 years ago. I think the info has spread that it is bad for your engine and the environment. And newer cars don't need it at all.

For one, have you ever written an unit file? It literally takes 3 minutes.

And unless you are working with e.g containerized services (which you create yourself), why would a service need anything from networkd? I have never encountered a unit file like that on my system, and I don't run anything apart from systemd and journalctl. No networkd (I prefer NetworkManager), no systemd containers, no systemd ntp. I wonder if I even have those installed, why should I?

And all my services run just fine.

That was not the argument though

You can use systemd without almost all of the sideparts.

No need to use networkd for example, networkmanager works great along systemd.

Actually most my systems use only systemd and journalctl to my knowledge. I prefer my established tools for all other jobs.

This is simply not true, there are many alternatives.

This can happen in DE and AT as well, especially in expensive regions.

Developers simply have the money/the better leverage by buying in bulk. Then there are developers that simply sell you the (tiny) lot for a premium, and let you choose between something they arrange, or building yourself. And the good lots are always gone long before the project is announced anyway.

The regulations for Passivhäuser (or houses with the respective efficiency rating) in fact require a ventilation system with heat recovery (since the otherwise necessary open-the-windows-like-a-savage-system wastes too much energy).

These nowadays come typically with moisture recovery (which arguably not always works well enough, depends on how much you still need to heat).

Yes, they do.

I have a Casio clock on my nightstand, it must be from before 2000, if not from before 1995. The display segments are failing, but apart from that: No button broke yet, calendar is still working, so is the alarm.

I'm confused. Are you suggesting that you know that I downvoted your comment? Twice? How should I achieve that you recon?

You mean the (approximately) three "weird" buttons to adjust date and time?

No, no and again no. The future were I need a smartphone to set my clock is not a good one for me, however you put it.

Learning to describe your problem.

Specific knowledge aside, I am always astonished that people not being able to coherently read and write is getting worse.

That's something YouTube, Snapchat, Instagram and Facebook don't teach I guess?

Highly subjective I would say.

Git is not horrible to use. And even before I was a proficient Git user, mercurial was giving a team of 5 people a lot of work trying to fix stuff that just works on Git.

May I ask why you are even using Python, if you need to work around the language in such ways?

These non-idiomatic uses might be shedding a few ms, yet they ruin the readability and maintainability of the code, most of all all tools like 2to3? Why not another (non-interpreted and thus faster) language? One where the idoms work in your favor?

Also, no need to support releases from 2004 and having to groan about it.

As much as I love Python, I get the feeling that you might have chosen the wrong language, or at least you used the wrong abstraction somewhere.

Yes, I know that Python 2.x and 3.x handle bytes entirely different, yet I cannot understand how Python and their release planning should blindly "bend" to the demands of a project using the language.

I understand you don't care about Python the least, but we do? We have to? I think that the maintainers simply had to move forward at some point, there has been a way too long grace period.

And Python is not ANSI C. I think what you want of Python is to be never-ever-changing C89 and gcc still supporting it (I think it still does?)

how small these "small issues" will be is of course a question of definition. Details, right? :)

Do you really wonder?

The answer would be "Of course!" and "Of course not!".

You don't need electricity to run a "computer". But as soon as you're trying to hook up this computer to the Internet, serving responses on an electrical network... I can't imagine how to do this without electricity.

Of course you're not looking for answers using a turbine, are you?

I don't think you completely understand the concept behind the Google Authenticator App, i.e. the standard it implements.

Which keys is it supposed to backup?

Everything else you said is sadly true.

Mind to explain how these concepts are rather different?

I think what you are proposing is to make an ideological fight out of this issue, that is exactly what the author describes as "a huge time-drain that does not make the app better" and exactly the opposite of what he meant with "choose your battles".

Let me say that I think you're morally right, but it is probably not a reasonable choice of actions for the author and the users of the app.

Do you mind if I take it as offense? I read the article. Any reason why you think I didn't?

How could you think such a statement is not offensive?

If the experiment was not flawed, it is pretty clear evidence, isn't it?

What factors did they miss in your opinion? Other machine brand? Water hardness?

Especially if you are looking for functional clothing. I am not fond of the idea of going back to run or bike in cotton, especially considering commutes and bad weather.

Are there alternatives to synthetic clothing?

It's not about plastic trash in general, the concern here is microplastics in the sewage/ocean/food chain.

And yes, I know that plastics lying around might eventually land in the ocean as microplastics. That doesn't mean that we should ignore the problems caused by synthetic clothing.

I was particularly looking for such (in fact these) questions while going backwards through the article again, and I must say:

I don't think you have a point here. All of these steps can be easily done while the lock is on the door. There are plenty of tools availabe to drill holes this way.

Nobody said it is "faster/slower/easier/more difficult" than existing attacks. It is a valid attack, it is quick and it makes almost no noise and worse: It isn't even obvious (you need to actively search for a tiny hole, otherwise you're just assuming all is OK)