Rebuild the World!

Some 40-years old computers still work (not all, but a lot of them), so if we're only going to use computers produced before 2010, we'll perhaps be able to use them until 2050ies. It is very possible some decent hardware (that is, controllable by the users) will become available on the market long before that period. Actually, some ARM-based SBCs available right today look controllable.

Brief search shows a lot of options, like this:

https://forum.puppylinux.com/puppy-linux-collection

https://www.slax.org/

I don't typically use live systems so I didn't check any of them. Let us know if you do.

Shurely we do. Check Antix (derivative of MXLinux, in turn, derivative of Debian). I've had to run their x86 release just a week ago.

P.S.: Sadly to say, DistroWatch filters would may to help you to select right distro for your purposes, but for a now these filters not working without javashit.

You can use Slackware Live, however you might want to build slackware live 14.2 or 15.0 yourself, because it seems that only slackware-live-current exist in 32-bit version, but the script can convert any slackware distribution.

Yes, definitely it is a universally bad thing. You can not prevent those people from distributing their, heh, shit around, making the whole world the stinky place we are now having. So people who provided those idiots with tools suitable for idiots, are actually to be held responsible for all the bad we're having from the ocean of python-written shit. And specially they are to be held responsible for all those who could become a decent programmer, but accidentally started with Python, thus closing their own path to writing good code.

BTW, this is not generally about making code easier to write. It is definitely easier to write in Pascal than in C, but writing in Pascal is not a catastrophe (unlike writing in Python), and it is not a problem to switch from Pascal to C when the time comes; this is exactly the way I recommend to learn programming from scratch. Those who start with Python, typically remain there forever; rarely a pythonist can stop being a pythonist and start working in C.

First of all:

> I didn't use the program after I have played with it for a couple of weeks and neither nobody else did

For such a program, there's absolutely no difference which approach you choose. Actually, there's no difference whether you did or didn't write it at all. External dependencies are intolerable because they trouble the users (and the package maintainers, if any), but your program doesn't have users nor maintainers, so there's no one to trouble.

However, if we talk about a program which is intended to be distributed to other people somehow, then let's see.

> In order to do that I first output the picture in netpbm format, which is extremely simple, then called imagemagick to convert it into the final png file.

It is a bit unclear here, how launching of the external program was actually done. I mean, I can't clearly see from your words whether you called the external program or your program did it.

If your program calls an external program on its own and can not work without it, it is definitely an external dependency and it is intolerable. However, in the setting you explain, there are at least two clear and short ways to fix this.

First is just to generate a file in the netpbm format and consider your program's job done. There may be a suggestion, e.g., in the documentation, that the user may convert it to any format he/she wants, using, for example, the convert utility from the ImageMagick kit, or any other suitable convertor. This won't be any dependency at all: indeed, your program works and does its job, regardless whether ImageMagick (or any other thing) is available in the system. The user might even upload the netpbm file to one of those online convertors, and get the picture in whatever format is desired. Actually, it is even possible the netpbm format appears exactly what the user wants, so no further conversion is to be done at all. Anyway, it is not your program's fucking business.

There's yet another option. You can provide a command line flag to let your program call the convert utility, and document it accordingly, e.g., if you have the convert utility, my program can, at your option, call it for you to get the PNG; give this flag at your command line to do so. If it is not invoked by default, hardly it can be considered a dependency, just an optional feature.

The critical factor here is if someone who packs your program in a package such as RPM or YUM or DEB or whatever else, has to specify it depends on something external or not. Usually this only takes place in case your program can not work at all without the thing it "depends" on.

> do you think it is a better approach than to use a library like libpng?

Well, since you asked: yes, I do think it is better to use a library, specialy knowing that libpng is not very large and can be easily packed together with your program, making no external dependency. However, this is not mandatory in any way. Generating netpbm is fine, too.

Thanks :-)

abolutely -> absolutely

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.