Ah yes, and this caching CMS will stably run on a very limited $1/mo VPS without any additional hardening on your part?

These "multiple available platforms" don't magically set up, evaluate, and administer themselves, after all.

Meanwhile, in the real world, my hosting costs are set to triple in two months thanks to my provider's hardware costs shooting through the roof. User donations currently cover about 1/2 of the existing cost. The rest comes out of my pocket.

BTW, even with >90% of all incoming requests blocked outright and most stuff static, at least 3/4 of all remaining hits (and all but a single-digit percentage of the actual bandwidth usage) are these crawlers. Most of that _is_ static content that doesn't change, but *that doesn't matter to the crawlers*

When the original authors made that choice, it was in a very different world from the one we live in today.

Since then, the underlying social contract was yanked out from underneath them.

Every time someone says "all you need [to do] is X", X can be generically translated as "invest a disproportionate amount of your time and/or money"

You have to ask yourself if what you are trying to accomplish is worth the cost; both up-front and on an ongoing basis.

Until your little site gets repeatedly DoSed by shitty crawlers, that is.

Hosting a *static*, low-bandwidth site is cheap. BBSes are very much not static.

It's a problem when everyone *but* the software's actual authors is making money off of it.

Freenet is also based on middle-out compression.

No. Trying to push 30TB into Freenet will be interpreted as an attack on the network by other peers and they'll disconnect from your peer.

Freenet is better viewed as a communication medium than a storage medium. Data is prioritized according to demand, somewhat like an LRU cache. You can't upload 30TB and expect the network to preserve it for you.

On liability, running a Freenet peer is more like running network infrastructure that automatically routes and caches other people's traffic than intentionally publishing it. US law explicitly recognizes this distinction in the DMCA's provisions for transitory network communications and system caching. We discuss this in more detail in the FAQ.

You obviously haven't tried Freenet. You can join our room on River and you'll see no spam, no fraud, no hate speech, none of that.

Decentralized doesn't mean unmoderated. Systems built on Freenet can be moderated however their creators and communities want. River is moderated.

The difference is that nobody running one service gets to decide what everyone else is allowed to run.

....Except that is, in of itself, not a crime.

(Meanwhile, it is widely documented that "illegal immigrants" are, as a group, far, far, far more law-abiding than actual citizens)

"criminal trespass" requires that (1) you are notified that you are not allowed on the premesis, and (2) Not leaving or [re-]entering knowing that you were not allowed to be there.

In other words, no crime has been committed at the time of the "arrest".

Your argument fails at the starting line. Age verification is "necessary" because the law of the land requires it.

You can wail and gnash your teeth all you want at application authors, OS vendors, and so forth, but at the end of the day, it's their asses (and bank accounts) on the line, not yours. Don't like it? Direct your wrath towards your governmental representatives; the odds are they were directly responsible for enacting the shitty regulations that everyone else is stuck having to implement.

That makes as much sense as getting angry at Intel because IBM chose to use the 8088 in the 5150 PC.

Except you're comparing apples to oranges. In the systemd case you manually created a unit, interactively started it, and manually debugged it (also interactively). In the sysv case, you ... copied a file, manually started it, and assumed it worked properly because no errors were reported on the console (which is _very_ dependent on the service+script in question)

If it failed to start in systemd (ie step 4), you'd have been told immediately. you could also run 'systemctl status oolama' to get the, well, status including the last 10 or so log lines including stdout/stderr/syslog output. no need to play with mucking with the logs. Which is a much better starting point than debugging "sometihng went wrong" in the sysv script world.

(BTW, you created a bunch of extra work for yourself in the systemd case, 3+4 are trivially combinable. And do you really want a service manager to automatically reload+apply changes you're making while you're interactively editing its configuration? FFS...)

In other words, you learned to do something one way, and now you're too damn lazy to learn anything else.