Skip to content

Home

Jump to bottom
Valentin Hilbig edited this page Aug 14, 2023 · 1 revision

What is this?

Well, it's basically for me and how I am structured. So if it is something for you, then go for it. And if you think you can contribute properly, go for it as well. But do not expect me to listen to you. This here is nothing like SystemD, I do not have a WDP (World domination plan). I just do everything for me alone.

Also I do not like build systems others than make. And best is to have no build system at all.

And I do not like (read: refuse to use) unauthenticated external resources. Hence I use git submodule a lot. Or rely on what is bundled in Debian. So I am definitively not on the bleeding edge side.

js this exactly such a submodule for reuse. For me it is very successful, because I already have implemented a lot of things with it. Most things only locally, so they are NOT public. However there are some which are a bit more public (but are likely of no interest for you at all):

This are exactly as the name suggests: Small little helpers, mostly build on top of es13.js. (They can be so small as with es13.js I can express complex things in just a few lines. Following the Unix philosohpy.)

Also do not expect something to be stable here. We have git. So if you are happy with what you use, then stay there! Why change? git submodules do not need to be on master.

So if you update to my latest source and that breaks things .. git divert is your friend. Perhaps I bugged something. Or I change it for some reason. Or none.

But ..

.. if you find a bug, something which affects security, then PLEASE open an issue. I am very interested in keeping things as safe as possible.

And ..

.. I am slowly switching from normal <script src> to <script type="module"> now. Why? Because even my oldest Mobile phone (which is able to speak to the net) has a browser which groks this (except one of my smart TVs, but this can be repaired with a Raspberry PI or Amazon Firestick). I still run some machines which I built up in the last millennium. Yes, of course, why not? But they get less and less important, now that even a Raspberry PI can emulate them faster than the machines run. With lower power. And more resources. And way faster Ethernet (those old machines usually only have 100 MBit/s, my backbone is still at 1 GBit/s, so a PI is enough, even that some newer machines could do 10 GBit/s already).

Hence there really is no need anymore to stay with all those machines from the stone age. If some fail to run the newer code, just replace it. And look forward.

This is exactly how I develop this here. If some code fails to serve me, I replace it. If something is missing, for me, I add it. And I do it my way. (Which is Open Source and Free to use, of course, without relying on so insane things like a Copyright.)

Also there are some other things I am really puzzled about:

  • Why is there a difference between Browsers and NodeJS?

    • No, I know why, really. Perhaps I even understand better than others why. But this still is unacceptable for me.
    • Hence things should work under NodeJS as under Browsers. Possibly mostly identical.
    • And I know about Deno. Is it part of Debain? Oh shit .. it's a Snap. (Well, Snap is another of such annoyance!)

  • How can others live with highly dangerous things like NPM? I really do not get it.

    • Also most often my VMs in the Cloud do not have a leg into the Internet, some even do not have DNS, hence it starts to become a bit difficult to use things like go which seamlessly request things from the Internet.

  • I do not understand window.subtlecrypto

    • I do understand crypto. (I am a Mathematician ..)
    • I do understand how to use window.subtlecrypto
    • I do not respect it, because the implementation is .. bad
    • For example, why is my sha256 (more than 10 times) faster than SHA-1 of SubtleCrypto? I am using native JS while Subtlecrypto should be able to utilize the specialized CPU hardware!
    • Well, perhaps I am unfair. I compare the implementations with billions of small byte calls instead of big files. subtlecrypto is async, hence it has a big overhead when used this way. However that is exactly what it should be for!

  • And I never will understand why window.subtlecrypto only works in HTTPS mode!

    • YOU NEED THE HASHES FOR SUBRESOURCE INTEGRITY! There is no difference between HTTP or HTTPS
    • Debian does perfect authentication for their apt repos, all on top of HTTP! No need for HTTPS at all, it even makes things worse (I can cache HTTP but not HTTPS, so caching the Debian repos is a breeze!)
    • And if you use subresource integrity properly, there is no security gain from HTTPS at all! Because when the sources are authenticated, I can implement a better cryptography than TLS offers.
    • TLS also is in the way of some authentication options, because TLS cannot be authenticated from JS at all.
    • For example, how to load something SECURELY from localhost? There simply is no way to do that with HTTPS, except by endagering the local browser by adding some obscure badly protected CA certificate of your own. NO WAY!

  • Me for my part thinks that HTTPS everywhere is the wrong thing to do.

    • Period.
    • Its the same thing for BEV everywhere. You definitively do not want a battery driven vehicle in Antarctica with temperatures below -70 C! And the alternative Hydrogen is no alternative at all, it is an environmental disaster by itself.
    • Yes, using HTTPS does more good then evil. Like BEV does more good than evil. BUT IT IS NOT THE LONELY SOLUTION TO EVERYTHING.
    • And hence, not supporting something with HTTP which is supported with HTTPS is the wrong way. Its simply extremely stupid.
    • Period.

  • Read: We must re-invent the wheel. And as there is nobody doing it a way I accept, it looks that I have to do it myself.

    • This is my some crypto primitives are re-implemented here.
    • Those which I need. And how I need them.
    • And I have not the slightest interest in implementing everything for others, too.

If you ask me what stack to use?

In the Web environment I mostly use:

  • HaProxy (SSL termination and Loadbalancer), NginX (Request routing) and PHP-FPM (if needed) as Middleware
  • JavaScript (Browser) plus WebSockets

For backends:

  • C
  • Pyton and NodeJS
  • In future probably go (now that I have found out how to use go in a non-network-environment)
  • and perhaps rust (for reproducible builds, but this works for C, too)

And as database the usual things:

  • PostgreSQL
  • MariaDB
  • CouchDB

I tested Mongo but stopped using it in favor of CouchDB. But I cannot recommend CouchDB for bigger projects either. Its behaves far too dangerous. The idea behind CouchDB is marvelous. But the implementation sadly very unsatisfying. If you need something like that, perhaps you are better supported doing your JSON things with PostgreSQL plus some JavaScript runners which can do, what CouchDB does.

Read:

  • As soon as the database size of CouchDB reaches your RAM size, you are very doomed.
  • Besides that, if you can live with all its problems, it is doing things very reliably.
  • But only if YOU know how to do it. I do, but you don't. Because things do not work as expected with CouchDB. Trust me.

What I do expect is that a database runs without problems until its size hits 10 times the RAM size. It should work as expected until it hits 100 times the RAM size. And it should be successfully useful until 1000 times the RAM size. My machines have 128 GB. And CouchDB becomes slow as hell, even that the raw data is only 50 GB.

But as CouchDB needs at least 5 times the database size of RAM (due to indexes etc.), these simple 50 GB (something I expect that it can be handled on my smartphone already) would need 250 GB of RAM to stay usable.

'Nuff said, out.

Clone this wiki locally