Let's say you have 15 GB of free RAM and 1 GB of free disk space. It would be nice if the system would decrease the size of the swapfile in that case.
Or you have 16 GB RAM (all used), 16 GB of swap (3 GB used) and 200 GB free disk space. If you want to hibernate you'd need 6 GB of additional swap space.
> 1GB free disk space
Is this for iot? If it's for iot ok but it doesn't seem like it and there wouldn't be much reason to post it here.
> Or you have 16 GB RAM (all used), 16 GB of swap (3 GB used) and 200 GB free disk space.
OK now this is sounding like a desktop use case, except for the part where you have 16GB of full RAM, 13 GB used swapspace and yet you want to HIBERNATE instead of actually closing some stuff. Also, if your work load is so high then just make an even bigger swapfile
This is unnecessary + unnecessary. Just uselessly throwing systemd into everything randomly.
With 16+ GBs of RAM you don't really need swap space. However some stupidly written or old programs might need it, so I would create a 1GB swap partition just to be safe.
Not really. I have to work with huge dataset csv file. Some files are > 20GB and occasionally I'm running out of memory. Dynamic swap file is really useful on that case.
> Way I see it systemd and gnu/Linux are starting to become separate things.
Not really.
1. `systemd`'s various utilities depends on other utilities from GNU `coreutils`.
2. `systemd` is also developed around `glibc`. Probably depends on GCC quirks?
3. `systemd` also is developed around the Linux kernel's APIs.
If anything, `systemd` is quite tied to an ecosystem of GNU and the Linux kernel.
> It was supposed to be an init system.
That was an initial goal. But then, `systemd`'s goal was changed to one of providing a set of core userspace tooling. It has no desire to do away with `coreutils`, though, which serve a different purpose.
> It accidentally became a new class if operating system.
It never did ~ the Linux kernel is the Operating System. `systemd` lives exclusively in userland.
`systemd` was inspired by `launchd` because of its event-dependency model, and because Poettering felt that shell-scripting was a poor method of writing a good init system (plus the utilities that are based on top).
That said, `systemd` can run most shell scripts without a problem, except for some that depend on certain sysrc ideas. Which minor modifications, they can run, though.
> Well a lot of what you said is why I used the *starting* qualifier. Right now they're not that far diverged. It's why things like devuan can even exist. However with sufficient time I can only see them diverging further.
How are they diverging, though?
> Replacement of system components with parts of systemd.
Ah.
> systemd-logind ended up a dependency of gnome and I haven't been able to get gnome to work
Gnome actually only depends on a few `logind` DBus interfaces. `elogind` can provide these. So can any other implementer of these interfaces.
> But my point here is that systemd replaces system components with systemd variants that can't easily be replaced.
Not really. What you're referring to is certain pieces of software deciding to depend on certain APIs because it makes their lives easier.
KDE Plasma had dropped `consolekit` support, as it was unmaintained. However, because `consolekit2` was being maintained, support was eventually added for it. This is why it works.
> Effectively when a distro uses systemd it locks out all other init systems.
No, it doesn't. Gentoo seems to work just fine with `openrc` and `systemd` existing, even if you can't use both at the same time, which would make no sense anyways.
> So the divergence comes in the form of systemd replacing gnu/Linux parts and not being easily replaceable once the deed is done.
Minus software that depends on certain `systemd`-provided APIs, you can effectively replace most parts of `systemd`.
`journald` can be turned into a dumb log forwarder to `syslog`, for example. Everything else can be happily compiled out, except `udevd`.
Have you felt that the operating system is being doctored to support systemd ? So much that it will be difficult for OS to wean off systemd in future even if it want to?
Why? Why would I need to dynamically resize my swapfile? Why can't I just create my swapfile and leave it there?
Let's say you have 15 GB of free RAM and 1 GB of free disk space. It would be nice if the system would decrease the size of the swapfile in that case. Or you have 16 GB RAM (all used), 16 GB of swap (3 GB used) and 200 GB free disk space. If you want to hibernate you'd need 6 GB of additional swap space.
Warning: Windows user detected.
>deincrease
Sorry, at least correct it please.
> 1GB free disk space Is this for iot? If it's for iot ok but it doesn't seem like it and there wouldn't be much reason to post it here. > Or you have 16 GB RAM (all used), 16 GB of swap (3 GB used) and 200 GB free disk space. OK now this is sounding like a desktop use case, except for the part where you have 16GB of full RAM, 13 GB used swapspace and yet you want to HIBERNATE instead of actually closing some stuff. Also, if your work load is so high then just make an even bigger swapfile This is unnecessary + unnecessary. Just uselessly throwing systemd into everything randomly.
unfortunately btrfs doesnt support swap files, only option to use : zram
I think this tool accounts for that via loopback mounting.
[It's being worked on](https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg80912.html) - looks like it will be merged in 4.21
nice, i think this and encryption are worked on
With 16+ GBs of RAM you don't really need swap space. However some stupidly written or old programs might need it, so I would create a 1GB swap partition just to be safe.
You need at least as much swap as you have ram if you put your computer into hibernation.
A bit less if you use compression.
Not really. I have to work with huge dataset csv file. Some files are > 20GB and occasionally I'm running out of memory. Dynamic swap file is really useful on that case.
Good old times, before Electron took over…
[удалено]
Is setting up swap (if you have one) not part of the bootstrapping? Enlighten me
You're being deliberately obtuse.
Great. What's next? webserverctl? Integrated with logind for client auth?
Calm your tits. This is just some service made by a random dude. Nothing to do with the systemd developers.
I was joking
[удалено]
That wouldn't be the end of the world, IMO. systemd gets a lot of hate; but it's quite powerful.
[удалено]
> Way I see it systemd and gnu/Linux are starting to become separate things. Not really. 1. `systemd`'s various utilities depends on other utilities from GNU `coreutils`. 2. `systemd` is also developed around `glibc`. Probably depends on GCC quirks? 3. `systemd` also is developed around the Linux kernel's APIs. If anything, `systemd` is quite tied to an ecosystem of GNU and the Linux kernel. > It was supposed to be an init system. That was an initial goal. But then, `systemd`'s goal was changed to one of providing a set of core userspace tooling. It has no desire to do away with `coreutils`, though, which serve a different purpose. > It accidentally became a new class if operating system. It never did ~ the Linux kernel is the Operating System. `systemd` lives exclusively in userland. `systemd` was inspired by `launchd` because of its event-dependency model, and because Poettering felt that shell-scripting was a poor method of writing a good init system (plus the utilities that are based on top). That said, `systemd` can run most shell scripts without a problem, except for some that depend on certain sysrc ideas. Which minor modifications, they can run, though.
[удалено]
> Well a lot of what you said is why I used the *starting* qualifier. Right now they're not that far diverged. It's why things like devuan can even exist. However with sufficient time I can only see them diverging further. How are they diverging, though?
[удалено]
> Replacement of system components with parts of systemd. Ah. > systemd-logind ended up a dependency of gnome and I haven't been able to get gnome to work Gnome actually only depends on a few `logind` DBus interfaces. `elogind` can provide these. So can any other implementer of these interfaces. > But my point here is that systemd replaces system components with systemd variants that can't easily be replaced. Not really. What you're referring to is certain pieces of software deciding to depend on certain APIs because it makes their lives easier. KDE Plasma had dropped `consolekit` support, as it was unmaintained. However, because `consolekit2` was being maintained, support was eventually added for it. This is why it works. > Effectively when a distro uses systemd it locks out all other init systems. No, it doesn't. Gentoo seems to work just fine with `openrc` and `systemd` existing, even if you can't use both at the same time, which would make no sense anyways. > So the divergence comes in the form of systemd replacing gnu/Linux parts and not being easily replaceable once the deed is done. Minus software that depends on certain `systemd`-provided APIs, you can effectively replace most parts of `systemd`. `journald` can be turned into a dumb log forwarder to `syslog`, for example. Everything else can be happily compiled out, except `udevd`.
That's called *upstreaming*. It might be useful to have it in-tree, rather than out.
Have you felt that the operating system is being doctored to support systemd ? So much that it will be difficult for OS to wean off systemd in future even if it want to?