bullen

Joined 11 years ago

Karma

750

Submissions

1,862

Member since

Sep 11

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

View on Hacker News

Recent submissions

Comment · 2 months ago

I have also put some thought to this problem and after reading some here are my definitive conclusions that still remain for all mesh networks to achieve:

- We need hardware that solves radio mesh problems:

  - Multifrequency (more than 8 bands and frequencies with different range) with programmable hopping between them (as opposed to LoRa default hopping which is random). I will use LoRa hardware for now on 169MHz to increase range and force frequency change in a non-random way. Still as mentioned LoRa rules cannot scale so we will have to build it in a non scalable manner and then change the limitations if adoptions ensues.

  - The radios need to be able to receive on many frequencies at the same time, atleast for the stem nodes.

- We need glue between old sync. IP/TCP/UDP (HTTP/SMTP/DNS) and async. IP2/"events" as he calls them.

- To scale geographical position is paramount and to remain independent of GPS we can use trilateration.

- The debate about encryption is a problem because it will have to evolve and to hardcode it into the base protocol will cause big disruptions down the road. I suggest the base layer is open and you apply encryption at the end; the reason for this is that privacy deters scalability and I prefer to have a truly scalable system that knows your position than the other way around. (also less chance the network can be used for military purposes then)

The resolution of range negotiation also has to be very granular: One freq. has to be the main "I'm here" channel and then dependent on density you have to releagate nodes to smaller and smaller range frequencies because a large city needs to cover a density of many thousand nodes per square kilometer.

So 169MHz is a good starting point (for range and less hops to reach bridge nodes) but you eventually need 433 and 868 too in the same device the main problem then becomes the antennas!!

To aim for complete decentralization over only radio is probably too optimistic, we could aim for distributed centralized independent networks instead with fiber interop so that mail and very simple web works on the base implementation to give immediate usability.

Finally a note on privacy, Tox is the only usable network that tried this and ohboy is it difficult to get any normal human being to adopt it when they have WhatsApp that has all humans on it allready.

To me unencrypted SMTP is a better attack vector because it is even more widespread and can be encrypted very easily later. Except of course destination encryption which works against scalability as I said previously.

The final reason I'm putting more energy into MMOs is that radio is easily disrupted and so far our existing internet show little technical reasons to abandon it yet. That can change in a heartbeat though.

Edit: Receiving my first meshtastic hardware for the C64 in a week or so but I still believe nobody has solved the scalability yet. I will eventually try to over at http://radiomesh.org

Comment · 2 months ago

No, because my apps crash = they are not able to allocate memory.

Windows uses 10GB, Chromium uses 10GB and leaks ~1GB per week... then I launch a game and that game crashes if I have left chromium open too long.

The odd thing things crash way before the total 32GB are used. Available memory is still 2-4GB. Probably it can't find a contigous space?

Comment · 2 months ago

Why does Windows 10 use 10GB of RAM if you have a total of 32GB?

And how come you cannot pretend to only have 4GB to make it use less?

I don't care about how slow the OS becomes, I care about software not crashing.

Comment · 3 months ago

"A normal Steam Deck consumes about 4 to 7 watts of total system power when idling on the home screen with low screen brightness."

Maybe HL2 brings zero overhead to idle then?

Anyway X86 is the past, risc-v is so completely lost into eternal future... only ARM really works right now.

Comment · 3 months ago

This is captured+streamed on the device with ffmpeg, but mobile phone video no.

Got a short of my own engine though: https://www.youtube.com/shorts/LKYX7E3A0Dk

Comment · 3 months ago

I think HL2 on portable 5W ARM linux is more interesting: https://www.youtube.com/watch?v=fl1nrDvmiII

Comment · 3 months ago

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.

Comment · 4 months ago

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?

Comment · 4 months ago

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!

Comment · 5 months ago

Everything in Java is defined behaviour, you need a VM with GC to remain sane.

Everything else is a waste of time!

Comment · 5 months ago

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!

Comment · 6 months ago

Some 3588 CMs are sold out.

So it might be too late as 3688 will be too hot...

Just like routers get dd-wrt when sold out!

Comment · 6 months ago

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

Comment · 6 months ago

XD Nope, more like self destruct! ;)