BehindTheBarrier

I don't think shorts are bad, but they aren't the reason I go to YouTube at all. They are just in the way.

Every time you open anything in office applications you get these small pop-ups

• See what changes others did?
• We added a new feature, do you want to see it?

I think it goes out of the cycle somewhat, kinda like all that is held up

If 100L rain down a day, and you use 10L for cooling then you will have still have 100L flowing but now only 90L for actual use. And then datacenters take up a significant amount of the total then you have a lot less to use elsewhere such as watering fields for example.

There used to be boxed ice cream with blueberry and egg yolk flavor. Loved it as a kid, got discontinued by the ice cream truck that had it. No replacement found. I probably won't even like it since I have forgotten the taste at this point.

Why wait and hope for C++ to get where modern languages are now? I know there's value in the shared experience in C++ that if adapted would make it stronger, but I can only see a development of C++ having to force a drop of a lot of outdated stuff to even get started on being more suitable.

But the language is just not comfortable to me. From large amounts of anything creating undefined behavior, the god awful header files which I hate with a passion, tough error messages and such. I also met a fun collision of C++ in Visual Studio and using it with CMake in CLion.

I've just started looking at rust for fun, and outside not understanding all the errors messages with the bounded stuff yet, figuring out what type of string I should use or pass, and the slow climb up the skill curve, it's pretty nice. Installing stuff is as easy as copy pasting the name into the cargo file!

Rust is just the prospective replacement of C++ though, people act like the White house said that C++ should be replaced by rust now. But the just recommend it and other languages, C# will do for a lot of people that does not need the performance and detail that the aforementioned languages target. Python is targeting a whole different use, but often combined with the faster ones.

C++ will live a long time, and if the popularity dies down it will surely be very profitable to be a developer on the critical systems that use it many years from now. I just don't think an evolution of C++ is going to bring what the world needs, particularly because of the large amount of existing memory related security vulnerabilities. If things were good as they are now, this recommendation would not be made to begin with.

It would kinda go along to "do not go gentle into the good night" like it was presented in Interstellar.

So you say, but it does make me flinch when it suddenly hits.

Just learning Rust for fun, but decided I wanted to make a simple website. I don't like web stuff that much, but seen htmx, so I gave that a shot. Found popular actix for the server side, and set out to make a simple blog.

Making a page is simple, using htmx is also simple. Setting out to create an blog that is all in a single evolving page? Not so much. Either you don't get the essential back and forward navigation, or you add that but a site refresh will call just the partial endpoint and screw things up. There's some quite nice work arounds, but at the end result is that sometimes going back will leave me on a blank site in one step.

I'm probably going to settle for each blog entry being a seperate page if I make the site public. Or just let the small flaws be there, because I hate sites these days being slow. So loading literally only the text/html that's supposed to change is very cool.

Next steps is going to remove chances of path traversal and reading literally any file on disk by modifying urls..., some markdown to html crate, and see how image loading works. If I ever get around to any of it.

I made do with my IDE, even after getting a developer job. Outside shenanigans involving a committed password, and the occasional empty commit to trigger a build job on GitHub without requiring a new review to be approved, I still don't use the commandline a lot.

But it's true, if you managed to commit and push, you are OK. Even the IDE will make fixing most merges simple.

It's probably more common that scientific notation is used. So 3.2 *10^4 or simply 3.2e4. From the little physics I had, you often used kilometers instead of something like megameters. Or used just lightyears when you got on a big enough scale.

I got a Peugeot 208. It's small, and ok in all aspects except the software. Typical bad car UI. It works with cabled Android Auto, so for long drives that's more than fine. But touch screen is still old, and the app/site hasn't let me log in for a few weeks now... So I can't remote start heating.

But it's a great car that I bought used, for driving to and from work. Looks good, yellow color, parking sensors and rear camera for my blind ass. But is also probably not available in America for all I know, I live in Europe.

Already been explained a few times, but GPU encoders are hardware with fixed options, with some leeway in presets and such. They are specialized to handle a set of profiles.

They use methods which work well in the specialized hardware. They do not have the memory that a software encoder can use for example to comb through a large amount of frames, but they can specialize the encoding flow and hardware to the calculations. Hardware encoded can not do everything software encoders do, nor can they be as thorough because of constraints.

Even the decoders are like that, for example my player will crash trying to hardware decode AV1 encoded with super resolution frames, frames that have a lower resolution that are supposed to be upscale by the decoder. (a feature in AV1, that hardware decoder profiles do not support, afaik.)