I know, and X11 uses TCP between server and client too. But still OpenGL has more longevity with emulation than Vulkan has, because hardware is not getting better. DDR3 feels like the peak of RAM. SSDs are terrible now.
After all Java is the ultimate emulator (all jars will run for eternity unless Java removes features like they did with Applets = biggest mistake in history), so will graphics APIs evolve that way too? OpenGL -> Vulkan with something like Zink?
I will still prefer X11 in a 100 years. And also OpenGL (ES) 3 because that is the first really cross compatible API (ARM and X86) and it has the last feature = VAO.
So that is where all that money is going, rewriting a perfectly functional implementation (that you can never retire because OpenGL hardware will remain in use for longer than Microsoft will last) with another more flawed one. Same as all other companies in other words?
I'm still waiting for a Vulkan feature that is worth anything. Multicore rendering is not interesting, specially not for voxel games (that need to use another CPU core for voxel duty and once that calculation is done the GPU part is super fast) and because (in general) you need the other CPU cores for gameplay (physics, networking, 3D audio) and OS.
This eternal "growth" of APIs and features leads to eternal waste of energy. I'm more interested in the non-obfuscation of the byte code, is that in? What about vibrant visuals?
I'm going to have to attempt installing Minecraft on my ARM Mac now! Edit: that was super fast and smooth, 120Hz!, no VV but I guess they need Vulkan for that? Edit2: The source names are now default! No obfuscation!
GG Mojang after all! Edit3 (last one): the new music is great!
You are right presharing is a requirement, unless you hash the keys used to encrypt the secret into the secret itself, but that can only be prooven later on a channel where the same MITM is not present.
Work in progress, that said presharing solve(d/s) enough for the world to dump DNS and HTTPS in a bin and light it on fire now, because nobody has the power to implement all the MITM needed if everyone "makes their own crypto" on top of allready shared secrets!
Yep, my distributed JSON over HTTP database uses the ext4 binary tree for indexing: http://root.rupy.se
It can only handle 3 way multiple cross references by using 2 folders and a file now (meta) and it's very verbose on the disk (needs type=small otherwise inodes run out before disk space)... but it's incredibly fast and practially unstoppable in read uptime!
Also the simplicity in using text and the file system sort of guarantees longevity and stability even if most people like the monolithic garbled mess that is relational databases binary table formats...
Most good projects end up solving a problem permanently and if there is no salary to protect with bogus new features it is then to be considered final?
And that means making closed port 53 illegal on your home fiber... good luck!
Also need to open port 25 outgoing on that same fiber.
And we all need routers that run dd-wrt, the problem is all routers that support dd-wrt are sold out because support always comes late in the production cycle.
It's hard work to self host, but it's the only work worth doing.
If your DNS port is closed by your ISP, you can't have people use your DNS server from the outside and then you need Google or Amazon which are not decentralized.
Also to be selfhosted you can't just forward what root DNS servers say, you need to store all domains and their IPs in a huge database.
Coroutines generally imply some sort of magic to me.
I would just go straight to tbb and concurrent_unordered_map!
The challenge of parallelism does not come from how to make things parallel, but how you share memory:
How you avoid cache misses, make sure threads don't trample each other and design the higher level abstraction so that all layers can benefit from the performance without suffering turnaround problems.
My challenge right now is how do I make the JVM fast on native memory:
1) Rewrite my own JVM.
2) Use the buffer and offset structure Oracle still has but has deprecated and is encouraging people to not use.
We need Java/C# (already has it but is terrible to write native/VM code for?) with bottlenecks at native performance and one way or the other somebody is going to have to write it?
After all Java is the ultimate emulator (all jars will run for eternity unless Java removes features like they did with Applets = biggest mistake in history), so will graphics APIs evolve that way too? OpenGL -> Vulkan with something like Zink?
I will still prefer X11 in a 100 years. And also OpenGL (ES) 3 because that is the first really cross compatible API (ARM and X86) and it has the last feature = VAO.
So will VV only work with Vulkan enabled?