Rebuild the World!

Sorry, I will not visit GitHub and will not let references to any of the "free" web-based repository hostings appear on this site, unless it is really needed (e.g. to propose a fork of an existing project)

Compiling build scripts means extra build-time dependency when cross-compiling (unless you have some multi-target compiler)

But it's interesting question: what is better?

1. Have external make-like utility (which is external dependency)

2. Have make functionality inside language

3. Have buildsystem inside source code

Second option seems to allow have less dependencies and useful when program not very complex, but makes language implementation more complex

> But just today, I was downloading a 4K movie with a speed of ~1Gbit/s

Generally speaking, I don't believe you (unless the movie resides in a local proxy cache or the like, which means it was not really from Internet). However, even if this really was a case, things like this don't happen very often, and if they do for a particular user, no one disallows to use "modern" active network equipment if it is really needed.

> On a few darknet sites, I have seen their owners write "Here is my email and my PGP key

I see no problem here at all, for two reasons:

• this scenario doesn't involve TLS/SSL;
• this is a matter of consent between end users, not between SMTP servers, and things like this don't force anyone to implement STARTTLS (which is a nightmare) within their MTAs.

Actually, using PGP/GPG in messages is a kind of thing which is only paid for by the people who need it. With STARTTLS being made mandatory, too many innocent individuals have to pay for it, that way or another. To my mind, mandatory STARTTLS, should it gets widely adopted, will make the email service as such unusable.

> I am just interested in the opinion of the author.

Today I had spare time so I responded, but this is exactly what the "preamble" on the taboo page is about.

I don't think there's much of practical use for rk86. As of pentium3 and later, please take a look at the FEDAnet project. It is now at its early development stage, but if we manage to achieve anything real there, older 32-bit computers (pentium2 and later) will be sufficient for everything but key generation, and key generation is only needed to start a new node. The master key may also be generated offline, so it is possible to keep kinda safe of all these IntelME, AMD ASP and the company (e.g. completely wipe and reinstall the machine which was used for key generation, before reconnecting it to networks).

BTW, as of rk86, do you have software for it, audio-encoded? And how do you store these? At my moscow home, I have a rk86, too, but I didn't turn it on for like 20 years :-) I'm affraid that the compact-cassette on which all the soft is recorded, won't work after all these years. Anyway, I now doubt if I ever get there again, so this question is more out of couriosity.

With your comment, you clearly demonstrate two things. First, you, being on someone else's territory, prefer to ignore the explicitly imposed rules, because it is clearly stated on this site that none of the explicitly enumerated taboos will ever be removed from the list, and we are (well, I am) not interested in discussing them. So perhaps I should have never made your comment visible, at all.

However, the second thing you demonstrate is more interesting, that's why I decided to write this response. Basically, it's this:

> JavaScript is bad not because it has loops, but because it's API is very very wide

This statement (on which all your reasoning is based) is simply, plainly and completely wrong. JS is bad because it is a program code, no matter what API the interpreter has and what capabilities the code has access (well, documented access) to. API is about what things the code being interpreted can do in a way intentionally provided by the interpreter. Limiting our consideration to this, we make fundamental and grave mistake. E.g., one may consider PDF format is okay because interpreters of PDF don't (intentionally) provide any access to the world outside of the interpreter's own small universe, which only consists of the pages to be rendered.

However, the reality is that we can never be sure there are no exploitable bugs in the interpreter. Never ever. Furthermore, real-world interpreters are always complicated enough so that we actually must assume that detection of an exploitable security hole in any of them is basically matter of time.

Taking this into account, we must realize that interpreters that analyse any data downloaded from an external (untrusted) source are dangerous, even the HTML renderers. This danger is much reduced (but not eliminated completely) in case the interpreter is intended to just make some 'appearance' basing on its input, and the danger increases sharply if the input format is intended to define some behaviour (as opposit to appearance), as it is, believe it or not, much easier to create working exploits when the attacker has access to a ready-to-run interpreter on the remote side. And here is the real thing. Revealing an exploitable hole in an HTML renderer may be of no help for the attacker because, although mathematically possible, it would likely take too much effort to do something real, and the time of people capable of writing exploits costs enormously high. Revealing an exploitable hole in a turing-complete interpreter is a jack-pot. Not because of its API, but because it is much much easier to control the victim program if it implements a turing-complete interpreter: it already has most of the things the attacker needs, so there's no need to catch it on the revealed hole, again and again, just to build up what the attacker needs on the remote side. Instead, the attacker just sends the program for the interpreter. It is always much easier than to compose machine code and push it through the small hole.

And yes, the margin is exactly where it is highlighted: on finite computers, turing completeness is never achieved, but access to any loop constructs is effectively just the same thing as having an interpreter of a programming language.

Please note that I'm not interested in wasting time discussing this. BTW, your last paragraph is a bunch of nonsense, but I won't comment on it.

> typo

Fixed, thanks

> "cult" fit better than "sect"

To what I feel, for cultists it is not universally true that they love to argue. Sectarians always do.

Hmmm, this is the most reported error of the new site, it was reported twice by email, three times here and even one time in Jabber :-)

Thanks to everybody for paying that much of attention!

Damn :) The problem was that this nonsense works on my home computer. Fixed, thanks.