From the link:
Requirements […] SystemD (sorry)
Boo… 
Seriously, thanks for sharing it with us, but systemd is a hard no for me, specially because I run Devuan (the systemd-free Debian fork – all of the Debian goodness without any of the systemd ugliness) where fortunately there’s no systemd.
So I guess I’m staying with killall -STOP browsername to pause them, and killall -CONT browsername to resume, and invoking the browser after ulimit -v in case I want to limit their memory usage.
WFM…
And if you use multiple desktops (and if you don’t, you should 
), a graphical representation of them is displayed to the right so you can also choose between desktops, as well as drag and drop windows on them to rearrange them between desktops.
I don’t like Gnome3 much (mainly because of the bloat), but this “hot corner” feature works really well, even for me that used FVWM before.
EMACS:
Even My Aunt Crashes the System
Eight-hundred(*) Megabytes And Constantly Swapping
Elsewhere Maybe Alternative Civilizations Survive
Easily Maintained with the Assistance of Chemical Solutions
Every Male Adolescent Craves Sex
These are av few of my preferred, look here for more.
(*)Eight Megabytes in the original, but updated to keep up with Moore’s Law
Makes sense. vi was my second editor on Unix, right after getting access to a VT100 – before that I used a ‘glass teletype’ (a teletype with a CRT in place of the printer) with no addressable cursor, so I had to use ed), and I continue to use it (or one of its reincarnations) daily.
My ‘IDE’ is screen with a window running vi to edit the source code, another with a shell where I run make, and optionally others to consult manual pages, etc. WFM…
I have been using only PC (Acer Aspire) , and my office noteook computer is also a PC (a Dell). I have the impression that Apple notebooks are more expensive. But both of my daughters have been using Apple notebooks (and iPhones). They say they Apple products are more reliable, although they tend to be more expensive.
I think perhaps the most relevant acronym for it is:
Escape Meta Alt Control Shift
The program and the computers it runs on have both improved dramatically, but it still relies heavily on key chords to make things happen. And the chord-oriented UI is the main reason why people switch to Vim or vi-mode or other interfaces based on key sequences instead of key chords.
Agree on relevance. Disagree on funniness 
The original emacs predates the Internet howver GNU emacs was invented by Richard Stallman from FSF.
I understand. Lennart Poettering is one of the worst people to ever happen to free software, and his creations have been among the most controversial and most destructive in Linux’s history. When problems need to be solved with a scalpel, he instead uses a wrecking ball and expects everyone else to rebuild everything around him afterward.
OTOH, I also tried using non-systemd distros for a while, and it took a huge amount of work to get a lot of things to function. While I’ve done a lot of distro-level work like that, I generally only do it if I’m getting paid. So eventually I swallowed my pride and went back to mainline Debian where things mostly “just work”.
It’s definitely possible to make memory jails without systemd, and that’s how I had been doing it originally… but you would need to modify the scripts and read up on how to do manual cgroup management in recent kernels. I had been using cgroups v1, and fighting over them with systemd, but when I updated to support cgroups v2, I also fixed the constant custody battles by using systemd’s API instead of bypassing it.
Agree on the computers having improved (Moore’s Law and all), but not so much on the program (EMACS), case in point:
$ ps auwx | egrep emacs\|vi | grep -v grep
REDACTED 4089 0.8 3.0 355524 62472 pts/0 Sl 12:29 0:00 emacs
So it’s no longer “eight megabytes and constantly swapping” (as I can testify was the case when I first had the displeasure of running EMACS about 40 years ago, on a VAX11/780) but indeed “eighty megabytes and constantly swapping”… and that’s for an instance of EMACS basically sitting there doing nothing, without even having opened a file (er, I mean, having “loaded a buffer” – the weird EMACS slang being par for the course).
For comparison, here’s vim, on the same machine (x86-64 running Devuan 4.0 Chimaera):
REDACTED 4095 0.0 0.2 8128 4064 pts/0 S+ 12:29 0:00 vi
And that’s not plain vi but full-blown vim, for eff’s sake… 
IMHO, there’s no excuse for any editor using more than FORTY-THREE times the virtual memory (and almost eight times the resident memory) of full-blown vim…
Have you tried Devuan? At least for me it’s basically no effort, worst case is having to create a /etc/init.d/DAEMON, in case DAEMON doesn’t already come with one, which is very rare (almost every daemon package in Devuan repo does come with it, so basically only in packages installed from somewhere else).
But is cgroups really necessary? Why not just plain ulimit -v? Then you don’t have to modify anything, nor deal with systemd or APIs or whatever.
ulimit -v works great here every time I have to limit a program’s use of memory.
Yes. That’s why I gave up on trying to avoid systemd.
Because ulimit is per-process, and that doesn’t help with programs like Chrome which use a lot of processes. The reason for using cgroups for this is because it handles process groups.
I switched from legacy tools to containers ~17 years ago with OpenVZ, then lxc, and now cgroups, and I don’t want to go back. It’s a much more powerful, more flexible way to isolate or partition computing resources… basically lightweight virtual machines with very configurable walls.
Humrmmrmr… IIUC, the limit will be imposed on all of them (ie, none of them will be able to go over the limit). So, to reach basically the same result, take the total memory you’re willing to use for all of chrome and divide by the number of processes (which AFAICS here, is constant and not dependent on number of windows/tabs/etc. I know it’s a gross approximation when compared to cgroups, but it’s what I do here – and it’s much simpler.
Agreed, and I do use containers – but for real isolation and partitioning, IME nothing beats real VMs, which is what I use here. After all, with containers, all of them are using the exact same kernel instance – and then you’re at the mercy of that kernel, just one privilege-escalation bug (of which people have been finding many per month) and your security is breached. To breach a VM, an attacker would need to exploit a bug in the VM hypervisor – which, by presenting a much much smaller attack surface than the whole Linux kernel, is much harder and less frequent to come by.
Just clarifying my position here: besides its complexity and defective design, the main reason I avoid systemd is because it’s not portable: use it, and you’re stuck with Linux. Granted, much better than being stuck with Windows or MacOSX – for now. In the future, if the Linux enshittification continues the way it is (with systemd leading the way), it could easily become a lot worse.
By using ulimit -v or standard VMs like I do, you can migrate to any POSIX system – exampli gratia, one of the BSDs. FreeBSD specially is a nice, fast, lean and secure system, and will probably be the one I will migrate to when Linux becomes unusable.
The browser adds and removes processes frequently, and it scales with the number of sites+tabs open. It’s already using ulimit or something similar to manage its own memory, plus an entire sandbox system of its own. This helps prevent individual pages from exploding, but it does nothing for the total resources used by the entire group as a whole. So I stuck the entire thing in a jail it can’t bypass.
Sure, if the goal is limiting the damage of hostile users, full virtualization holds up to attacks better. But that’s not my goal.
My goal is to stretch limited resources farther, and simplify administration. Containers provide a lot of extra features with zero overhead and near-zero inconvenience. Basically just run one extra command, and suddenly the browser behaves a lot better. It still shares the same kernel, the same filesystem, the same network, the same login session, the same memory pool, the same sound card, the same graphics card, etc… but it isn’t allowed to use excessive amounts of resources.
A hypervisor, however, is a heavyweight solution which adds a lot of complexity and administration overhead, enforcing boundaries I don’t want for this task, using resources less efficiently in exchange for tighter security I don’t need. It’s a great tool sometimes, but this isn’t one of those times. It gets me farther from my goals, not closer.
Thanks for the clarifications, @Toykeeper, and by and large I agree with you.
But (as I commented right before you posted this), you realize you are locking yourself up into Linux (and worse, into a systemd-infec^H^H^H^H^Hequipped Linux), right? You already can’t easily move to Devuan even if it’s Linux and basically Debian, as you have become dependant on systemd for your cgroup management.
I understand your point re: “stretch limited resources farther” – but just ditching systemd would free a a lot of these resources, in terms of CPU, RAM and disk space – last time I checked, systemd and the associated crap it brought in with it were real resource hogs.
As per “enforcing boundaries”, these can be crossed mostly transparently between VMs and between them and the host system – most VM systems implement a shared clipboard, so you can copy & paste among them without a second thought, ditto shared directories (I hate calling them “folders”) so they can all see and read and write to the same files.
I understand security is not so important for you, but standard VMs are available basically everywhere (so you aren’t locking yourself up into any system), are far from complicated (with VirtualBox or Libvirt it’s basically a point-and-click process, and there’s also a CLI available) and if you take care to use snapshots, very little additional resources are spent (as the common memory and disk space is then shared among similar VM instances).
I started using VMs basically for everything way back in 2001, and my machine at the time was a laptop with a single-core Pentium-III-based CPU and 256MB of RAM and a 4GB hard-disk, and with careful usage, I didn’t have any issues – of course, everything is much larger these days, but I still use VMs in modest machines and it works great (for my use case – YMMV, of course).
Case in point, at this very moment I’m running an entire HomeAssistantOS instance in a KVM VM instance in my 8GB Raspberry Pi 4 – and when we’re camping away from an AC plug, me and the wife use it instead of our notebooks (as it draws less than 5W when compared to the 30W our laptops need) and we can use a MATE GUI environment complete with LibreOffice, many browser windows and tabs open (granted, not as many as in our laptops) and everything works very acceptably – and all the while HomeAssistant keeps running in its own VM in the background.
OK I will stop the proselytizing now 
– just wanted to make sure you (and anyone else reading this) has the same data I have. And thanks for listening and responding.
(edit: bumped the wrong key and it caused the post to send halfway through; I deleted it so I could finish it first)
Systemd is not required to use cgroups. It’s also not the terrible monster many people think it is. Debian’s leadership made an informed decision when they switched, with years of deliberation beforehand, carefully weighing the tradeoffs and voting to select the solution the Debian developers collectively found least objectionable. While I’m not totally happy about it, I do at least understand why it happened. Most of my career has been spent developing distros, and I was involved in making two different init systems, and I can’t really fault Debian’s decision. But I still reserve the right to shake my fist at the sky and yell “Poettering!” when his creations cause problems.
As for Linux itself, I’m not really concerned about being locked in. It’s open-source and has the largest developer and user base of any kernel in the world. It has been overall the best kernel for decades, and if that ever changes, its replacement will almost certainly prioritize making migration easy.
I’'m not really concerned about cgroups going away either. I’ve replaced my solution 3 times already, and each time it was because something better came along. If the system I’m using now is ever phased out, it’ll probably be because it got upgraded.
Anyway, long story short… cgroups are a handy way to make mainstream browsers behave better.
I have Windows because I like games. If it wasn’t for that I would use Linux. Apple isn’t even on the table for a desktop
Do you have a funeral for the death of the sentient pattern you’ve generated every time you reboot your PC? 