domi

But why does it end up washing out colors unless I amplify them in kwin? Is just the brightness absolute in nits, but not the color?

The desktop runs in SDR and the color space differs between SDR and HDR, meaning you will end up with washed out colors when you display SDR on HDR as is.

When you increase the slider in KDE, you change the tone mapping but no tone mapping is perfect so you might want to leave it at the default 0% and use the HDR mode only for HDR content. In KDE for example, colors are blown out when you put the color intensity to 100%.

Why does my screen block the brightness control in HDR mode but not contrast? And why does the contrast increase the brightness of highlights, instead of just split midtones towards brighter and darker shades?

In SDR, your display is not sent an absolute value. Meaning you can pick what 100% is, which is your usual brightness slider.

In HDR, your display is sent absolute values. If the content you're displaying requests a pixel with 1000 nits your display should display exactly 1000 nits if it can.

Not sure about the contrast slider, I never really use it.

Why is truehdr400 supposed to be better in dark rooms than peak1000 mode?

Because 1000 nits is absurdly bright, almost painful to watch in the dark. I still usually use the 1000 mode and turn on a light in the room to compensate.

Why is my average emission capped at 270nits, that seems ridiculously low even for normal SDR screens as comparison.

Display technology limitations. OLED screens can only display the full brightness over a certain area (e.g. 10% for 400 nits and 1% for 1000 nits) before having to dim the screen. That makes the HDR mode mostly unuseable for desktop usage since your screen will dim/brighten when moving large white or black areas around the screen.

OLED screens simply can't deliver the brightness of other display technologies but their benefits easily make it worth it.

I would second getting a separate microphone/headphone instead of a combined headset.

All the headsets I owned over the years were significantly worse in audio quality and broke after a few years, usually something related to the microphone.

I went with a Sennheiser 598 with a Modmic for years, which was ok but switched to a beyerdynamic DT 1990 Pro about 4 years ago.

So far my favorite out of all the headphones I owned. Very clear sound, comfortable, actually "Made in Germany", and they still provide replacement parts on their website. Replaced my ear pads just a month ago or so.

The Modmic is decent but there is a lot of room for improvement, I was never able to find a proper alternative though.

Sodium-based batteries currently have a lower energy density than lithium-based batteries so they are only useful in some applications.

When I worked help desk, a coworker of mine took a call where someone called in because one of the thin clients was on fire. The user was advised to call 911.

Well, did he try to turn it off and NOT back on again?

And yet I do not think I will be using my Bosch in 25 years because some cheap internal plastic part will have broken down while the Makita would still run.

I don't think you can import pfSense configurations into OPNsense. I switched from a DIY pfSense box as well and redid the config.

You can look for a converter or install pfSense onto it though.

Because it's dope.

Also, according to their website the 10 and 25 Gbit/s packages cost the same per month.

Also, still cheaper than my 1 Gbit/s connection.

The RFC you linked recommends that no new X- prefixed headers should be used.

The paragraph you quoted does not say you should use the X- prefix, only comments on how it was used.

See section 3 for the creation of new parameters: https://datatracker.ietf.org/doc/html/rfc6648#section-3

I still work on software that extendively uses X- headers.

I wouldn't worry too much about it. The reason they give is mostly that it is annoying if a X- header suddenly becomes standardized and you end up having to support X-Something and Something. Most likely a non-issue with real custom headers.

We don't have many unit tests that test against live APIs, most use mock APIs for testing.

The only use for this header would be if somebody sees it during development, at which point it would already be in the documentation or if you explicitly add a feature to look if the header is present. Which I don't see happening any time soon since we get mailed about deprecations as well.

My dad has an old Makita cordless drill from 1995 which he used for everything from assembling Ikea furniture to drilling holes in cement walls. Complete metal innards, full metal case, battery that's big and heavy enough to bludgeon somebody to death with.

Until one day I bought a fancy new Bosch cordless screwdriver with Li-ion battery, brushless motor and 1/4 the size and weight of the Makita.

At first he laughed at me for buying a toy, then he tried it. He ordered one as well the week after and uses it pretty much exclusively since then.

Still keeps the Makita box and drill around purely for the retro look but even with fresh batteries the amount of torque they put out is not even in the same league.

Obviously that is the exception rather than the rule and most technological advances went into making companies more profits instead of building better products, but there are some advancements that made power tools better. Li-ion batteries and brushless motors being two of the big ones.

I don't really get the purpose of a header like this, who is supposed to check it? It's not like developers casually check the headers returned by an API every week.

Write them a mail if you see deprecated functions being used by a certain API key, probably much more likely to reach somebody that way.

Also, TIL that the IETF deprecated the X- prefix more than 10 years ago. Seems like that one didn't pan out.

They are expensive but I run a OPNsense DEC740 and have no issues with my Gigabit fiber, even without modem and the PPPoE overhead.

You can still try playing with hardware offload on/off and if you use PPPoE, it runs on a single core by default.