HN user

bullen

748 karma

https://multiplayeronlinestandard.com https://tinspin.itch.io

Posts7
Comments1,818
View on HN

I have been running uConsoles with CM5 (2712 and 3588 with 16GB RAM) for 6 months as daily drivers.

They are ~$500* and present the same ARM problems/opportunities.

But they are completely silent (no fan, the case is the heat sink).

My 6600(3050) desktop from 2016(2024) with replaced SSD(2021)/RAM(2025) (they age like milk) now gets little use and M$ will soon sleep with the fishes.

*Hard to get now as the 3588 that has linux for uConsole is out of stock and the Raspberry one is rare and more expensive by the day.

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 will VV only work with Vulkan enabled?

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!

100% agree the problem is modular RAM can't handle the timings of the SoC.

There is a new modular RAM standard for precisely that but knowing Apple they will want to make their own.

SSD should be easy but since RAM does not last that much longer you still need to resolder that after 5-10 years!

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!

Circular arguments, wishful thinking and all...

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...

Yes, but we need to decentralize DNS first!

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.

No root certificate is decentralized.

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.

I would say:

1) Use HTTP (secure is not the way to decentralize).

2) Selfhost DNS server (hard to scale in practice).

3) Selfhost SMTP server (also tricky).

4) Know and backup your router (dd-wrt or iptables).

JSON over HTTP is the way.

XML is not bad for certain things too; even if I understand the legacy of abuse.

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?

I wrote a Win32 app 20 year ago, but the limits to how it handles memory made things confusing when you loaded large amounts of data into the GUI.

I would say Java Swing is still the peak of GUI development. Works flawlessly at close to native speeds (GPU acceleration and all) on all platforms including Risc-V that did not exist when it was developed!

The JVM is the emulator!

What is the advantage over just using this:

  var source = new EventSource('pull?name=one');
  source.onmessage = function (event) {
    document.getElementById('events').innerHTML += event.data;
  };
http://talk.rupy.se/event.html

If you need bi-directional communication, then you should consider using WebSockets instead.

Or you just do a HTTP request?

The more interesting metric is running HL2 on Pi4, Pi5 and 3588:

Pi4: 20 FPS same when using ffmpeg to stream to twitch. 5W

Pi5: 40 FPS idem as above. 10W

3588: 300+ FPS and rock solid 60 FPS streaming to twitch. 15W

So 5090 is not even interesting for gameplay. More polygons and larger textures do not make games more fun to play.

AAA has peaked and C++ does not even deliver interesting games any more. C#/Java are way better alternatives for modding.

It's still flakey, but with the open panthor driver things are working well.

It's usable as is.

By the time linux catches up hardware might be very expensive or missing completely.

So my thinking is buy now, use as is, and maybe later we get better software... The point is the 3588 can actually replace my X86 desktop for ALL purposes except Unity/Unreal which I am glad to not run.

To write this article without mentioning the 3588, is like writing about Venezuela without mentioning oil.

Pi 5 and N150 are completely meaningless since before they came into existence.

Also the price of 3588 increases by batch so you can still get them at almost launch price (4GB was $70 now $110, next batch probably ~$150 by now if nothing improves)