I don't know if that's idiomatic webcomponent or not but that looks unmaintainable, even for such a minimal component, imagine once it grows. It's not separating presentation from state and logic. querySelector need to match classes and elements in the markdown. Mutating textContent is going to run out of sync as soon as you have more than one event source doing the same. Those are all problems that React solve by separating state and only rendering in one path.
This would mean every single user gets 10 uniquely personalized ads per year.
Even if that wasn't hilariously unreasonable by several orders of magnitude, if the moderation cost was was included in the cost of serving ads, this would all self regulate and only serious actors would participate. Treating it as a public bulletin board while still raking in a percentage of the impressions for sure is a nice business model, but not what's best for the rest of the society. Maybe ads just shouldn't be such a lucrative business.
Gerrit manages stacked changes with standard git tooling, except for the tiny change-id hook. Similar stable change identifier is also what enables Jujutsu to do its magic. Standardizing around something like this would be greatly beneficial, instead a ”gh” CLI is now needed to push a commit.
JJ, Gerrit, codebutler, and I think a couple of others have all basically agreed upon a syntax for change IDs and they are converging their prior ad-hoc formats into one; but last time I checked, the request to the upstream git team of "please don't silently drop the change-id header during rebase or amend" was met with bike-shedding about all the other hypothetical benefits that alternative formats could hypothetically provide, so universal support for the header as used in practice today is still missing D:
(I would love to be proven wrong if there's been some progress that I didn't get the memo about ^^)
This is roughly the current state of things as I know about it, that said I haven't read a lot of git's mailing list lately so it's possible that there have been some other developments.
Invisible until moused over, or scrolled by other means. Barely visible even then. In the wrong place. It may be "just styled", but it's certainly not fine.
Even without AI, a large part is also that everything easy and relevant has already been asked and answered. 10 years ago, there was still demand for low hanging ”how do I reverse a string in programming language X”. On top of that, languages and libraries today tend to have a lot better documentation.
What’s left to ask now is ”plx fix my homework” - [pastes error log unique to the posters environment]. Something that Claude is very good and very tolerant at.
Does this mean that AV1 on Youtube will finally not melt my CPU, while my nvidia GPU is asleep, or is this just an enabler that will require more work to build upon?
If the GPU is new enough to include a hardware AV1 decoder.
For NVIDIA, that means Ampere or newer (RTX 30xx or newer).
Turing or older (RTX 20xx or older) do not have support for AV1.
Vulkan has the advantage of providing a unified interface for video decoding.
Previously on Linux some programs were written to use only the Intel API or only the NVIDIA API. Fewer programs could use any of the 2 video APIs. (The AMD GPUs also supported the Intel API.)
With Vulkan, the same program should work with any GPU.
Vulkan has specific functions for different video codecs. To be able to use the hardware GPU support for AV1, the program that uses Vulkan for video decoding must also include support for AV1, i.e. it must invoke the corresponding Vulkan functions.
For now, it is not clear if Firefox already includes support for all codecs. In the initial version they could have included only partial Vulkan support, for instance only for H.264 video decoding, with the intention to add complete Vulkan support in some future version.
reply