bullen

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

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

- To scale 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 clear text 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 beleive nobody has solved the scalability yet. I will eventually try to over at http://radiomesh.org

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?

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.

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

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

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

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!

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

Everything else is a waste of time!

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!

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!

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

XD Nope, more like self destruct! ;)

Meanwhile HTTP keeps working just fine and is decentralized.

Just "add your own crypto" on top, which is the ONLY thing a sane person would do.

3... 2... 1... banned?

Meanwhile CVS just keeps working fine...

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

Dying or stabilizing?

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?

What is the GPU? Some sort of FPGA?

Edit: Also picture missing from the page, the keyboard:

https://codeberg.org/TechPaula/LT6502b/src/branch/main/Image...

Edit2: Found a few suspects in BOM: ATF1508AS-7AX100, ATmega88PA-AU, ATmega644P-20A

Would love to know what each will do!?

The previous one hints a bit: https://codeberg.org/TechPaula/LT6502

A blog entry: https://www.maddox.pro/?p=414

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.

Let's Encrypt is not part of our friends here.

DNS is easy for yourself, but if you host it for others (1000+ of people) and it needs to have all domains in the world, then it becomes a struggle.

Wow, thanks!

Also if people need more food for (decentralized) thought:

https://datatracker.ietf.org/doc/html/rfc2289

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.

No I meant this but for C# is a whole lot more complex:

http://move.rupy.se/file/jvm.txt

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!

Also have a HTTP only website.

For me it would need vanilla linux or atleast MacOS.

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?