I would classify GPU compute based rendering as software rendering though. My original comment was written with that in mind. This is a semantic discussion though which is IMO not super important.
If you do GPU-based software rendering, I would highly advice using RT instead of raster for visibility. It's simpler and likely also faster. But HW acceleration there also beats compute, in both, although you can achieve good results without acceleration too.
Sadly you can't access RT cores with CUDA, you need to use a graphics API like Vulkan or D3D12. You can make a fast ray tracing based renderer using pure GPU compute, but it'll still be slower than using RT cores.
And even with GPU compute, you benefit from HW acceleration with the HW texture unit.
Games industry might suck on average, but I'd argue that graphics programming niche does not. There are lots more users of graphics than games, like visualization, simulation, etc. Coupled with the fact that good graphics programmers are extremely rare, it's a surprisingly good career. This is in very stark contrast to game developers, artists and so on, which seem to have much harder time getting good quality jobs. Of course, both job market supply and demand is small, so changing jobs might not be easy.
I'd very much argue against somebody making game development their career, at least from job security grounds. But graphics programming is different.
Sadly, Vulkan is really painful way of learning graphics programming. Doing almost anything requires large amounts of boilerplate. Almost everything you need to do, for example to make shadows, requires just 10x more code than the technique fundamentally requires.
For learning graphics programming, in my opinion, writing software renderers is much more enjoyable path. Code is less, the code you write touches fundamental and not boilerplate. Downside is that code will be slower as you will lose HW acceleration.
At least personally, the point of graphics programming or making "engines" is not to make games. It is to make real-time graphics, implement interesting approaches etc. If you are making a game instead of an engine, you will probably never focus on the graphics / rendering part, and instead need to focus on gameplay, 3D modeling etc. For many people this is explicitly not what they want: They want to make engines, not games.
The term "garbage collection" does not mean that the language has some mechanism of automatically reclaiming some memory. If it did, C would be a garbage-collected language. The term is not used in such way.
Now, of course reference counting can be used as a part of a garbage collector. But that doesn't mean any language that allows you to implement reference counting as a library, is a garbage-collected language.
By that definition even C has garbage collection. Automatic storage duration types have compiler-determined lifetime and automatic deallocation.
If the definition of a word/concept does not match how the word is used in real life, the definition is wrong. After all, semantics is about common understanding of concepts. If your definition of a word doesn't match how it's used, using that definition is not beneficial to use.
Window AC's don't really work with the styles of windows that are common here (at least in Finland). The windows typically swivel from the side, with multiple planes opening separately. They don't open vertically like in the US. This is also why window AC units are not sold here.
But getting a portable AC unit is relatively simple, they definitely don't need "re-engineering the environment". Sadly most portable AC's here are single-hose units which are not great. They are cheap though with prices similar to yours, cheapest at around €200. Mini-split systems are very common though as a retrofit: On apartments you can almost always put the outside unit on the balcony.
It's because there's a big heat wave in certain parts of Europe right now. I'm not American (I'm Finnish), but I have also thought how weird it is that in central/western europe AC is so rare. I has definitely been needed for decades already in places like Germany and France.
I really wish Windows had a way to show what kernel callbacks are registered and execute on each call. Even better would be to have actual timing data on these callback. Using that one could much more easily to debug and potentially uninstall misbehaving software.
I dislike the non-specificity of "models" here. Different models have different attention architectures, and can therefore have significant differences in long-context behavior. It's true that long context is an issue can most models do drop off in quality, but I would not extrapolate behavior of old models to new ones.
The comment I answered implied that all Europeans have a disdain for working hard. This is not the case. The point was to say that if work and achievement was discouraged like the commenter said, Europe would regress as a continent.
"Europe" is not a single entity with uniform opinions. As an European, I would much rather have hardworking people and """workaholic""" culture than regress to an underdeveloped culture fueled by laziness.
As an European I really _do_ mind buses. I try to avoid riding them as much as possible. They are dirty, smelly, and really cramped with little legroom. I would really hate living somewhere where I was forced to use them, and would rather move elsewhere.
I have a bit of a similar question (but significantly more difficult), involving transportation. To me it really seems that a lot of the models are trained to have a anti-car and anti-driving bias, to the point that it hinders the models ability to reason correctly or make correct answers.
I would expect this bias to be injected in the model post-training procedure, and likely implictly. Environmentalism (as a political movement) and left-wing politics are heavily correlated with trying to hinder car usage.
Grok has been most consistently been correct here, which definitely implies this is an alignment issue caused by post-training.
Traditionally, economy are typically divided into three sectors: Agriculture, industry, and services. Service industry contains everything from nursing to software development and sales. The problem with this division is that there is an extreme productivity gap within work in the service industry. A software developer's work can serve 100 million people at a time, when a nurse can only serve one customer at one specific time.
The reason why highly developed economies have become so service driven is because they have become sort of bimodal: The cost of labor is such that only jobs that are productive enough (profitability per hour) are done in these countries, and jobs that absolutely have to be done there to sustain the population. Jobs in the middle, everything that is not highly profitable or location-dependent, is offshored to lower-cost countries due to the cost of labor. This results in these developed countries having issues: Cost of living is high due to labor cost and there's high economic inequality due to wildly differing productivity.
The solution would be to bring these "mid-productivity" jobs back to developed countries. However, the main roadblocks still remain: The cost of labor is too expensive for most of these jobs to be competitive globally. However, I think there might be a way to do this in the near future: Advancements in robotics would mean a higher level of automation for industrial work, meaning more industrial jobs would become viable in high-cost countries. Each worker would be productive enough that the cost of labor is not critical anymore.
To make this happen, I believe it's important to ensure that the country is viable for this kind of manufacturing: Energy supply needs to be abundant and cheap, workforce needs to be educated, outside the "elite" students, and there needs to be low trade barriers. Low trade barriers are needed, because virtually all manufacturing is part of a global supply chain where parts cross many borders before the product is sold (and (high-value) products are sold globally). Additionally, the viability of automation will vary between different parts of the supply chain, and so you likely cannot automate everything.
If you do GPU-based software rendering, I would highly advice using RT instead of raster for visibility. It's simpler and likely also faster. But HW acceleration there also beats compute, in both, although you can achieve good results without acceleration too.