Also difficult to manage fake websites duplicating the look and feel. Scamming people into giving access or passwords.
A native app which is installed once from a good source is more secure, i feel.
731 karma · joined November 30, 2017
Also difficult to manage fake websites duplicating the look and feel. Scamming people into giving access or passwords.
A native app which is installed once from a good source is more secure, i feel.
So maybe Cloud Agents are in AI death camps?
You are talking about the Value of AI, but the key is the Revenue of AI.
If AI companies cannot get the Revenue to pay for all those investments, somebody is going bankrupt.
A trillion is a lot of money to cover.
Cue some story here on a bank or airline somewhere still relying on cobol backend servers.
These LLM conversions really seem to make modernization of large parts software layers possible!
There just is not the kind of immigration culture as in America. Some people don’t even have a notion why anyone would want to come to Europe.
Git is bad at such volumes of binary assets, textures, models, sounds, etc.
- The P4 cpp api was apparently designed before any modern Cpp std lib was available. And is at best archaic, and stringly to use.
- P4 encoding support is pain in the ass to configure. And ensist on adding or removing bom to files.
It sounds like what you think as positives are exactly the things parent comment thinks as negatives.
All cpp alternatives are more wordy.
I wonder how this conversation wound go if the was an as terse, but also typesafe cpp alternative.
So, it does not have to be soldered.
These branded projects become difficult to remember when everything has a random non-mnemonic name.
A different durability requirement.
A Ryobi is not bad, if it fills your needs, but might not be enough for heavy use.
I think Valve is trying to leverage the Steam Storefront into a full-fledged Platform. It is not quite there yet.
As such, they have invested a lot of effort into the compatibility layers, which allows gamedevs to support Steam Devices with no extra effort, or minimal effort, which is very important business vise.
As a gamedev, you essentially get a bonus platform for your game without extra dev effort!
> Not even those that have Android/Linux NDK builds, bother with porting to GNU/Linux.
It is a huge hassle to make a new build to a new platform. You double build system, release management, and testing. Compared to just one plat. Games are complicated, and testing all the dynamic behaviour is also complicated.
Making just a Win32 build really saves resources.
Also Win32 has been a stable api for a long time. Linux apis tend to change, and old games don't get re-built. The win32 build is therefore also provably a lot more long lived, compered to anything you build on linux.
Thats also important because of the Dont Kill Games effort and so on.
After all, if the Software does not work, its just a Paperweight
A tangent, but what is Obvious depends on what you know.
Often experts don't explain the things they think are Obvious, but those things are only Obvious to them, because they are the expert.
We should all kind, and explain also the Obvious things those who do not know.
Contrast this with ip6, which is a completely new system, and thus has a chicken and egg problem.
Neither of which is in EU, which is exactly the point. Should be an EU one which is usable...
char buf[12];
sprintf(buf, "%s%s", this, that); // or
strcat(buf, ...) // or
strncpy(buf, ...) // and so on..says
> Increase the capacity of the vector (the total number of elements that the vector can hold without requiring reallocation) to a value that's greater or equal to new_cap.
I belive that the behaviour of reserve() is implementation defined.
After some pondering, and reading the rust documentation, I came to the conclusion that te difference is this: reserve() will grow the underlaying memory area to the next increment, or more than one increment, while reserve_exact() will only grow the underlaying memory area to the next increment, but no more than that.
Eg, if grow strategy is powers of two, and we are at pow(2), then reserve() may skip from pow(2) to pow(4), but reserve_exact() would be constrained to pow(3) as the next increment.
Or so i read the documentation. Hopefully someone can confirm?
The higher level the language, the less interest there is to manually manage memory. It is just something to offload to the gc/runtime/etc.
So, i think this is a no-go. The market wont accept it.