Hacker News Reader

Containerization solves 99% of those problems and more, such as not having to worry about conflicting dependencies, share of common resources, etc.

I would say shared hosting is now more popular than ever, with a twist: similar to the shift that has happened from multi-user mainframes to personal computers to ubiquitous computing (ie individuals having multiple computers), self-hosters are also now hosting not one but many websites/apps per server.

I am not sure how the status quo is different from your suggestion, or rather, how your suggestion is an improvement over that?

The original post is talking about static sites: https://sitejs.org/

And mentions a VPS:

Sync and deploy to your own VPS.

I shouldn't have brought up LAMP / PHP, because that confuses the issue.

The point is that you should not use a VPS to serve static content! You will not do as good a job as maintaining the OS and web server as a professional. Just use shared hosting!

You can also use Github Pages or whatnot, but that goes against the philosophy of centralized cloud providers.

Commodity shared hosting is very portable between providers, because it's just a Linux box, without "cloud" stuff. That's all you need for static pages. Use rsync or git.

This page looks really ugly but it will give you a sense of how many independent providers there are: https://www.webhostingtalk.com/forumdisplay.php?f=4

> self-hosters are also now hosting not one but many websites/apps per server

When was this not the case? Self-hosters are generally more resource-constrained, and thus reusing hardware makes more sense. It was pretty common already 20 years ago.

My bad, I should have added "with ease" at the end of that sentence. It was not impossible of course, but I personally find easier now.

These days shared hosting with multiple tenants is more commonly known as "serverless". A bit of a misnomer since servers are involved, but it's the common term.

From what I understand, the term "serverless" is usually used for "on-demand pricing of computational resources (such as CPU, RAM, and bandwidth)."

https://en.m.wikipedia.org/wiki/Serverless_computing

Shared hosting is usually much more straightforward in many ways, including flat-rate pricing.

another thing I like is stuff like "lambda" where you can run a function instead of a whole server application for every api request! Wait, I think I've seen this before.

    functionname.cgi?param1=val&param2=val

(replace "cgi" with your favourite php/pl/py/cfm/whatever)

Differences between shared hosting and "serverless":

- Monthly or yearly billing vs hourly (as the sibling mentioned). I think my plan is $9/month or something, plus $16/year for domain name.

- Single server vs. multiple servers. AWS Lambda is great if you actually need to scale up, but you don't need that for serving a website. A single machine can serve hundreds of static websites.

- You can get commodity shared hosting from dozens of providers, but you can get serverless from only a few "big cloud" providers, which goes against the ethos of the small web. That's because writing and maintaining the custom software to scale up is a big undertaking.

The original post is talking about static websites. You don't need anything running on the server for this! So all you need is shared hosting, and you won't even use the PHP part.

https://news.ycombinator.com/item?id=29804920

Many people forgot about lamp stacks, or it really entered the wayside. Then again people push/deploy LEMUR stacks now. https://www.nginx.com/blog/introducing-the-lemur-stack-and-a...

But agree on people not knowing shell, even cloud shell on azure/aws - people like to touch things and really enjoy the UI for setting up networking rules, load balancers and more.

Still so much fun, cgi - php and apache in general, the mid 00's were an exciting time were you could do so many things. I enjoyed hosting a website on port 80 from my residential cable/roadrunner connection and editing live pages and seeing it reflect instantly (sure you could just do localhost, but back then even port 25 and such were open, easily letting you run your own mail server and more.)

But the fastest way to get a page on the web nowadays would be github pages, you can do it in less than 10 mins, but I guess if you have a server already imaged, you can do "sudo apt-get install lamp-server" and get started that way.

The LEMUR article you linked says:

> This blog post was published on April 1. That’s a huge hint ;-)

Not sure what to think about this...

The biggest problem with shared hosting is security. It's common for everyone's processes to run as the same "www-data" user. It can be made secure, but it isn't common and most shared hosting is powered by off-the-shelf piles of shit like cPanel which are Swiss cheese when it comes to security.

No I don't believe any shared hosting does this (at least not ones anybody pays money for). Dreamhost and Nearly Free Speech definitely don't.

This might have been true 20 years ago, but I doubt it was true 10 years ago, and definitely not today. Maybe some tiny universities had janky setups like this.

Fun fact: shared hosting providers maintained OS virtualization for Linux years before Docker existed.

https://en.wikipedia.org/wiki/OpenVZ -- initial release 2005

I'm not quite sure but it also appears to have pre-dated cgroups. If you pack many users together on a server, you will want something like cgroups to prevent neighbors from DOS-ing each other.

This was a fork and wasn't in mainline Linux.

So they actually had MORE isolation than running as separate Unix users, not LESS.

(edit: I'm not sure exactly which shared hosting providers used such Linux kernel forks, but I'd be interested in anyone with direct knowledge. From using the shell on various shared hosting providers, I know they have pretty custom configurations with more isolation than stock distros.)

This page is a little fuzzy: https://en.wikipedia.org/wiki/Virtuozzo_(company)

Nope, most shared hosting is still like the OP comment’s description.

Then of course you have companies like Cloudflare and Netlify where their shared static hosting is not the traditional lamp/cpanel stuff, and certainly have internally developed platforms/serving technologies where security and sandboxing is very likely top of mind.

Companies of Cloudflare and Netlify ilk are the exception, but most cheapo shared hosting (and shared hosting has to be cheap to compete), is still very much multi-tenant with security concerns across the board.

See this comment, it's probably only mod_php, which you don't need for serving static sites:

https://news.ycombinator.com/item?id=29804968

I've used 3 shared hosting providers, all of which provide SSH access. And when I ssh in, and type "ps", I see my own processes, not the processes of anybody else. They are running as a different user.

You can have unique SSH users and still have all the PHP code run under a shared user on the web server. The machine you SSH in is most likely not the same as the one running your PHP code even.

Years ago I worked at a small hosting company and avoiding this situation was definitely on our minds. There are a lot of approaches to it under eg. Apache: https://cwiki.apache.org/confluence/display/HTTPD/PrivilegeS...

My bet would be that most larger shared hosts have implemented some type of solution for this, but perhaps some smaller ones haven't.

Yeah so I use Python and FastCGI with Dreamhost, which runs as a separate process and separate user.

I think mod_php (Apache shared library) is the the thing where every PHP site runs as www-data, but I thought that FastCGI was preferred these days over mod_apache. FastCGI is a separate process, which can run as a separate user, communicating over sockets.

But the original post is about STATIC websites, so this won't come into play. The main point is that you shouldn't spin up a VPS to serve static sites! You'll be burdened with maintaining the OS and web server.

Shared hosting is basically as easy as Github pages, with more choice of provider (in keeping with the philosophy of the small web).

I can't imagine that the process level is an issue here – we're not talking military, do we?

Other than that, prefer zero-knowledge designs and you can often reduce to the danger of vandalism. Have a friendly hoster and/or backups for that case.

While not military, most websites handle some kind of personal data (even IP addresses count as such for GDPR purposes) and a large chunk of the world has regulations that impose penalties or at the very least requires disclosure (bad PR) for data breaches.

Considering how easy and relatively cheap it is to get your own dedicated bare-metal server, I don't see any reason to bother with shared hosting anymore.

do as you please, but none of my family could responsibly maintain a dedicated server.