9 ms·

I'm not a Linux expert, but I thought that systemd was generally hated?

by europeanguy 4y ago

tkuraku 4y ago
Seems pretty great to me. Never understood the hate.
- nomel 4y ago
  I was sold after a single session of writing a couple of dependent services. Logging, retries, cleanup. Everything was so ridiculously straightforward, rather than a bunch of bash hacks and lock files. I have trouble believing that people who loath it so much have actually sat down to read the documentation.
zargon 4y ago
> bedrock of delight It might be sarcasm?
- deleted 4y ago
  [deleted]
plaguepilled 4y ago
I would say it really depends on the context! Some reasons systemd is bad: - Its a "big" for small docker containers (which is part of why a lot of people like Alpine Linux). - It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script. - the binaries are all a lot bigger in terms if SLOC and in terms of storage space than the solutions they replace. This makes auditing the code more of a chore and is a big argument against it in certain security environments. - (my main gripe) systemd produces vendor lock-in from seemingly unrelated apps. A lot of packages which indirectly depend on a systemd functionality need to be patched to work on OpenRC Gentoo, for example. Some arguments for systemd: - systemd abstracts process management. This can be fantastic for scripting and security (again, context dependent) - systemd by default kills services on log out (which is great for desktop - but can be an obstacle for servers). This is a good default behavior from a security perspective. - systemd has some parallelization of init, making start up more predictable (because something falling over is less likely to nuke the whole procedure - again good for desktop) - systemd provides a lot of tooling to stop you doing things the "wrong" way. For example, systemd-analyze-security provides configuration tips to harden your system ========== In general, I would say that systemd is a very impressive tool and helped a lot of distributions standardise how they handle boot. I wish it did not impact downstream development the way it does though.
- yjftsjthsd-h 4y ago
  > Its a "big" for small docker containers Aside size, last I looked it required a lot of hoop-jumping to get systemd to run inside docker at all.
  - klodolph 4y ago
    I think the idea of running systemd inside docker (or vice versa) is a little redundant to begin with—systemd and docker share a number of features.
    - yjftsjthsd-h 4y ago
      It's unusual, but there are occasionally times when it's nice to run multiple processes in one container, and a proper service manager would be useful. Usually I see supervisord used for that kind of thing in practice.
  - RealStickman_ 4y ago
    Iirc using systemd in Podman is much easier.
- panick21_ 4y ago
  You can easily have it not produce binary logs. Other software depending on Systemd isn't really Systemd responsibility. Its not systemd fault that almost nobody uses OpenRC.
  - plaguepilled 4y ago
    I think its a bit of systemd's issue since it's attempting to cover a large range of functionality. The way it provides that functionality is important. Re: the binary logs - true, but the core point that its not text by default is still a (small) issue IMO. Not ideal default behaviour.
    - gupnop 4y ago
grepLeigh 4y ago
I've developed a distrust for anyone who hates on systemd in 2022, especially if their rationale is vague dogma like "it does more than 1 thing, it's not Unix-like!" It's usually a signal that the person is not a practioner. Systemd is the most important and well-developed Linux framework, besides the Linux kernel itself.
- iotku 4y ago
  Feigned certainty is often a indication of the opposite. In many cases people just absorb someone else's opinion on topics just in an effort to feel informed. I'm not going to say I'm never guilty of it myself, but often asking even for the slightest bit of further explanation collapses that or otherwise just leads to repetition.
- Jach 4y ago
  I don't trust anyone's opinion, for or against, unless they've used alternatives. I've used systemd, I'll probably use it again, and I'll keep hating on it if someone gets me started. Fortunately on my own systems I've been a happy OpenRC user instead.
  - grepLeigh 4y ago
    My S/O is a Gentoo maintainer so this comes up often in my household!
    - Jach 4y ago
      As a longtime user I thank your S/O, you're lucky to have them!
  - boudin 4y ago
    I've used both (OpenRC and systemd). I like the simplicity of OpenRC and still uses it on a few servers running on Gentoo, but on a laptop/desktop I think systemd is a better fit, having user services with user level logging for example.
- traverseda 4y ago
oconnor663 4y ago
It's one of those things where people who hate it talk a lot about that, but people who like it don't have much to say.
fuckstick 4y ago
It’s not generally hated. It has a cadre of permacritics that are very vocal and often dramatic, and some of them often pop up in threads such as this one, that is all. It’s especially pathological since there are alternatives - if you hate Lennart, Redhat or whatever, use something else and move on. Meanwhile millions are using it to get shit done without much drama. It’s been years since I filed a bug on systemd, but that’s what grown ups do when inevitable bugs are encountered, not make themselves and everyone miserable because they deeply integrated some dubious 1970s Unix philosophy into their personality.
ruuda 4y ago
There are two types of software: those that everybody complains about, and those that nobody uses.
otabdeveloper4 4y ago
Yes, it's so hated that it's impossble to find a Linux system that doesn't use it.
HNDV 4y ago
>thought that systemd was generally hated? If it was generally hated there would be a lot more support for the distros that don't have systemd. There isn't. Except for alpine, all of them are extremely niche, half of them are dead, the other half barely have enough people to stick around for a release a year. Even alpine is kinda niche, it's mostly used as a way to make lightweight docker containers, rather than as a distro that stands on its own, the fact it uses musl as its libc means you can't use it on a server that has nvidia gpus for machine learning, you can't use it on a desktop where you need a browser capable of DRM, you can't use it on a personal computer if you ever intend to install a video game etc. I have -yet- to hear anyone in my life actually use something like Devuan, the systemd-less fork of Debian, in a production environment. Six years after their first release, instead of standing on their own as a distribution, they're still deeply angry and obsessed with systemd and this is the level of professionalism they exhibit on social media : https://twitter.com/DevuanOrg/status/1586963662295687169 https://twitter.com/DevuanOrg/status/1586963662295687169 Of course, one of the twitter comments underneath is "systemd macht frei". One of the things the official devuan account retweets : https://twitter.com/jaromil/status/1544618996833583104 https://twitter.com/jaromil/status/1544618996833583104 "It's 2022 and the master of systemd is now working for Micro$oft https://phoronix.com/scan.php?page=news_item&px=Lennart-Poettering-Out-Red-Hat https://phoronix.com/scan.php?page=news_item&px=Lennart-Poet... this the last bit @phoronix omits. This is a classic cybernetic strategy: to become the master of a feedback loop you create and continuously adjust the framework in which nodes interact." I think that says enough about the sort of irrational people we're dealing with? People who hate systemd are very, very vocal, and highly unproductive.
- encryptluks2 4y ago
  I think that is an overstatement. I use systemd but there is legitimate criticism and even a questionable conflict of interest in the creator now working for the competition. People working against the best interest of the community is a real threat that shouldn't simply be ignored. However, so far systemd has worked out alright for me so I can't complain too much but the documentation is still lacking in certain areas and so doing things that are easy to understand with a traditional script based RC can become frustrating when you are trying to figure out the systemd-way to do things.
terom 4y ago
By a vocal minority.
agumonkey 4y ago
It started with bad press because author made pulseaudio and its design didn't appeal to many (lots of features but missing pieces, not due to dev but market forces and drivers). So when the same guy says he's gonna rewrite pid1 with a radically different design people went ballistic. My personal opinion is that proper dependency based init systems are amazing but I'm not fond of some slightly superficial aspect of systemd (syntax, parameters, logic, config files).. to the point I think in a few years someone may make a cleaner variant.
esarbe 4y ago
From my experience this was never much more than a very vocal minority.
tux3 4y ago
A couple years ago, absolutely. To decide whether to generally hate systemd, and with what intensity, you should follow a curve that decreases proportionally with how long ago the change was made, and that starts as high as the multiplication of how much churn it causes times how old the thing it replaced was, all of which is of course multiplied again against the buggyness curve When pipewire replaced pulse, despite pulse being well established and a core desktop component, there was very little churn and few bugs. People not impacted did not mind at all that a major component was changed, or that it did many things and bundled three completely different protocols into one, arguably not very reminiscent of Unix Philosophy™ I would confidently predict that a change as large as systemd, to a component as old, and that causes as much churn (rewriting, relearning) would follow a roughly similar hate curve, only distinguishing itself by whether it was more buggy or less buggy than the predecessor. It's churn people hate, not change. The lesson I learned is that you can make large changes to the system, it's only hated when it forces humans changes.
- alxlaz 4y ago
  It's worth remembering that much of the churn was caused not by having to rewrite configuration, but by the multitude of bugs that plagued systemd early on, and the way they were treated did not help. systemd upstream was extremely difficult to work with and made a lot of people reluctant to embrace change, because when something didn't work -- which we all understood was natural for software developed in the open -- you were pretty much screwed. Shell scripts and duct tape were bad but it could take less time to fix something than it took to get people "up there" to admit that they're really looking at a bug, not a feature. I ran systemd very early on because it gave me some things I liked from SMF but I completely understand why so many people hated it. It's a (suite of) program(s) with good ideas that was hampered by extremely poor maintainership and relation with other open source projects.
- how_gauche 4y ago
  Pipewire broke me lots of times during its development and rollout, and that's okay, because new software has bugs and in some of my other use cases "hey it's a lot better than Jack". What I'm not going to do is carry a grudge against the maintainer for decades? I've been using Linux since Slackware installed from a pile of floppy disks. I'm extremely happy with systemd (desktop and server) and view it as one of the most important UX advancements ever made in the Linux sysadmin space. It replaced a smorgasbord of broken nonsense with a unified and thoughtful system that is objectively superior to what it replaced. I suspect a lot of the extreme reaction to systemd is not just resistance to change, but based on an emotional attachment to the rag-tag heterogeneity it made obsolete.
UI_at_80x24 4y ago
On my laptop, systemd is awesome; I love it. Everything works together nicely. On my servers, systemd gets in my way, tries to do too many things, and gets in my way more then it helps. On a laptop things are much more dynamic. From sleep/hibernation/wifi-LAN-wifi (+/- VPN) switching/etc.... these fiddly bits were much harder to manage on Linux for DECADES then they are now. The reboot interval on laptops is huge compared to servers. An init system (plus all the extra plumbing) work well together. On servers however; I HATE systemd. For logging, networking (and DNS) alone systemd wastes so much more of my time and gets in my way. I think the need for an 'improved' init system was always a red herring. I've never had a service race-condition, or other conflict that didn't take more then 10 minutes to fix in the 30 years I've managed *nix servers. There was one time where I was stumped why my VPN server kept failing to start at boot but came up fine if I restarted manually. My dyslexic ass inverted the script number (ie. 13 instead of 31 or something like that). That was just a face-palm embarrassment.
- lrvick 4y ago
  Systemd should never be used on a server. Or any other desktop init system for that matter. Production systems should never be changed or administered in place, only replaced. Servers should be immutable appliances. They do not need a package manager, or systemd, or ssh, or even a shell. Such things are developer tools and only belong in development environments like workstations. A production filesystem should contain a kernel, an init binary, and either a container runtime or a static binary of your target application. At most a production init binary just needs to setup virtual filesystems and be a reaper for a target application binary.
  - effie 4y ago
    > Production systems should never be changed or administered in place, only replaced. Servers should be immutable appliances. They do not need a package manager, or systemd, or ssh, or even a shell. Such things are developer tools and only belong in development environments like workstations. That is a very restrictive work methodology (unikernels,exokernels). Although interesting and certainly useful in some cases (high security, rare updates), Bryan Cantrill was partially right on this - in the real world, we often need to debug stuff running in production and support paying customers who require that. Your idea of "production systems" and "servers" seems very specific and the "should" statements are often not true in practice. Developer tools definitely belong on the server too, you need them to determine how to build your stack binaries in the best way for the OS and HW architecture there and keep them updated and secure.
excsn 4y ago
Hehe, I remember some people complaining about it. I never could hate SystemD once introduced to it as an infrastructure engineer. The difference was night and day in Debian (from wheezy to jessie). Setting common sig handlers, restart on exit, etc. are just one-liners with unit files. In the previous one, SysV, it was an annoying incantation especially if you were a newbie, like me at the time, or product engineer who was dabbling. You could easily screw it up. Some non infra engineers cursed the SysV files and loved the SystemD unit files. Now I use dynamic user and the other security features in my unit files and wonder how many lines it would have taken to do that in SysV, so the complaints are laughable at this point.
traverseda 4y ago
Less hated ad time goes on. I still think it's architecturally stupid (look at openrc for something that accomplishes similar goals but better), but it's been a while since it's broken anything terribly for me, or introduced any terrible security vulnerability. It's not great, but it's not actively hurting.

I'm not a Linux expert, but I thought that systemd was generally hated?

tkuraku 4y ago

Seems pretty great to me. Never understood the hate.

nomel 4y ago
I was sold after a single session of writing a couple of dependent services. Logging, retries, cleanup. Everything was so ridiculously straightforward, rather than a bunch of bash hacks and lock files. I have trouble believing that people who loath it so much have actually sat down to read the documentation.

zargon 4y ago

> bedrock of delight It might be sarcasm?

deleted 4y ago
[deleted]

plaguepilled 4y ago

I would say it really depends on the context! Some reasons systemd is bad: - Its a "big" for small docker containers (which is part of why a lot of people like Alpine Linux). - It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script. - the binaries are all a lot bigger in terms if SLOC and in terms of storage space than the solutions they replace. This makes auditing the code more of a chore and is a big argument against it in certain security environments. - (my main gripe) systemd produces vendor lock-in from seemingly unrelated apps. A lot of packages which indirectly depend on a systemd functionality need to be patched to work on OpenRC Gentoo, for example. Some arguments for systemd: - systemd abstracts process management. This can be fantastic for scripting and security (again, context dependent) - systemd by default kills services on log out (which is great for desktop - but can be an obstacle for servers). This is a good default behavior from a security perspective. - systemd has some parallelization of init, making start up more predictable (because something falling over is less likely to nuke the whole procedure - again good for desktop) - systemd provides a lot of tooling to stop you doing things the "wrong" way. For example, systemd-analyze-security provides configuration tips to harden your system ========== In general, I would say that systemd is a very impressive tool and helped a lot of distributions standardise how they handle boot. I wish it did not impact downstream development the way it does though.

yjftsjthsd-h 4y ago
> Its a "big" for small docker containers Aside size, last I looked it required a lot of hoop-jumping to get systemd to run inside docker at all.
- klodolph 4y ago
  I think the idea of running systemd inside docker (or vice versa) is a little redundant to begin with—systemd and docker share a number of features.
  - yjftsjthsd-h 4y ago
    It's unusual, but there are occasionally times when it's nice to run multiple processes in one container, and a proper service manager would be useful. Usually I see supervisord used for that kind of thing in practice.
- RealStickman_ 4y ago
  Iirc using systemd in Podman is much easier.
panick21_ 4y ago
You can easily have it not produce binary logs. Other software depending on Systemd isn't really Systemd responsibility. Its not systemd fault that almost nobody uses OpenRC.
- plaguepilled 4y ago
  I think its a bit of systemd's issue since it's attempting to cover a large range of functionality. The way it provides that functionality is important. Re: the binary logs - true, but the core point that its not text by default is still a (small) issue IMO. Not ideal default behaviour.
  - gupnop 4y ago

grepLeigh 4y ago

I've developed a distrust for anyone who hates on systemd in 2022, especially if their rationale is vague dogma like "it does more than 1 thing, it's not Unix-like!" It's usually a signal that the person is not a practioner. Systemd is the most important and well-developed Linux framework, besides the Linux kernel itself.

iotku 4y ago
Feigned certainty is often a indication of the opposite. In many cases people just absorb someone else's opinion on topics just in an effort to feel informed. I'm not going to say I'm never guilty of it myself, but often asking even for the slightest bit of further explanation collapses that or otherwise just leads to repetition.
Jach 4y ago
I don't trust anyone's opinion, for or against, unless they've used alternatives. I've used systemd, I'll probably use it again, and I'll keep hating on it if someone gets me started. Fortunately on my own systems I've been a happy OpenRC user instead.
- grepLeigh 4y ago
  My S/O is a Gentoo maintainer so this comes up often in my household!
  - Jach 4y ago
    As a longtime user I thank your S/O, you're lucky to have them!
- boudin 4y ago
  I've used both (OpenRC and systemd). I like the simplicity of OpenRC and still uses it on a few servers running on Gentoo, but on a laptop/desktop I think systemd is a better fit, having user services with user level logging for example.
traverseda 4y ago

oconnor663 4y ago

It's one of those things where people who hate it talk a lot about that, but people who like it don't have much to say.

fuckstick 4y ago

It’s not generally hated. It has a cadre of permacritics that are very vocal and often dramatic, and some of them often pop up in threads such as this one, that is all. It’s especially pathological since there are alternatives - if you hate Lennart, Redhat or whatever, use something else and move on. Meanwhile millions are using it to get shit done without much drama. It’s been years since I filed a bug on systemd, but that’s what grown ups do when inevitable bugs are encountered, not make themselves and everyone miserable because they deeply integrated some dubious 1970s Unix philosophy into their personality.

ruuda 4y ago

There are two types of software: those that everybody complains about, and those that nobody uses.

otabdeveloper4 4y ago

Yes, it's so hated that it's impossble to find a Linux system that doesn't use it.

HNDV 4y ago

>thought that systemd was generally hated? If it was generally hated there would be a lot more support for the distros that don't have systemd. There isn't. Except for alpine, all of them are extremely niche, half of them are dead, the other half barely have enough people to stick around for a release a year. Even alpine is kinda niche, it's mostly used as a way to make lightweight docker containers, rather than as a distro that stands on its own, the fact it uses musl as its libc means you can't use it on a server that has nvidia gpus for machine learning, you can't use it on a desktop where you need a browser capable of DRM, you can't use it on a personal computer if you ever intend to install a video game etc. I have -yet- to hear anyone in my life actually use something like Devuan, the systemd-less fork of Debian, in a production environment. Six years after their first release, instead of standing on their own as a distribution, they're still deeply angry and obsessed with systemd and this is the level of professionalism they exhibit on social media : https://twitter.com/DevuanOrg/status/1586963662295687169 https://twitter.com/DevuanOrg/status/1586963662295687169 Of course, one of the twitter comments underneath is "systemd macht frei". One of the things the official devuan account retweets : https://twitter.com/jaromil/status/1544618996833583104 https://twitter.com/jaromil/status/1544618996833583104 "It's 2022 and the master of systemd is now working for Micro$oft https://phoronix.com/scan.php?page=news_item&px=Lennart-Poettering-Out-Red-Hat https://phoronix.com/scan.php?page=news_item&px=Lennart-Poet... this the last bit @phoronix omits. This is a classic cybernetic strategy: to become the master of a feedback loop you create and continuously adjust the framework in which nodes interact." I think that says enough about the sort of irrational people we're dealing with? People who hate systemd are very, very vocal, and highly unproductive.

encryptluks2 4y ago
I think that is an overstatement. I use systemd but there is legitimate criticism and even a questionable conflict of interest in the creator now working for the competition. People working against the best interest of the community is a real threat that shouldn't simply be ignored. However, so far systemd has worked out alright for me so I can't complain too much but the documentation is still lacking in certain areas and so doing things that are easy to understand with a traditional script based RC can become frustrating when you are trying to figure out the systemd-way to do things.

terom 4y ago

By a vocal minority.

agumonkey 4y ago

It started with bad press because author made pulseaudio and its design didn't appeal to many (lots of features but missing pieces, not due to dev but market forces and drivers). So when the same guy says he's gonna rewrite pid1 with a radically different design people went ballistic. My personal opinion is that proper dependency based init systems are amazing but I'm not fond of some slightly superficial aspect of systemd (syntax, parameters, logic, config files).. to the point I think in a few years someone may make a cleaner variant.

esarbe 4y ago

From my experience this was never much more than a very vocal minority.

tux3 4y ago

A couple years ago, absolutely. To decide whether to generally hate systemd, and with what intensity, you should follow a curve that decreases proportionally with how long ago the change was made, and that starts as high as the multiplication of how much churn it causes times how old the thing it replaced was, all of which is of course multiplied again against the buggyness curve When pipewire replaced pulse, despite pulse being well established and a core desktop component, there was very little churn and few bugs. People not impacted did not mind at all that a major component was changed, or that it did many things and bundled three completely different protocols into one, arguably not very reminiscent of Unix Philosophy™ I would confidently predict that a change as large as systemd, to a component as old, and that causes as much churn (rewriting, relearning) would follow a roughly similar hate curve, only distinguishing itself by whether it was more buggy or less buggy than the predecessor. It's churn people hate, not change. The lesson I learned is that you can make large changes to the system, it's only hated when it forces humans changes.

alxlaz 4y ago
It's worth remembering that much of the churn was caused not by having to rewrite configuration, but by the multitude of bugs that plagued systemd early on, and the way they were treated did not help. systemd upstream was extremely difficult to work with and made a lot of people reluctant to embrace change, because when something didn't work -- which we all understood was natural for software developed in the open -- you were pretty much screwed. Shell scripts and duct tape were bad but it could take less time to fix something than it took to get people "up there" to admit that they're really looking at a bug, not a feature. I ran systemd very early on because it gave me some things I liked from SMF but I completely understand why so many people hated it. It's a (suite of) program(s) with good ideas that was hampered by extremely poor maintainership and relation with other open source projects.
how_gauche 4y ago
Pipewire broke me lots of times during its development and rollout, and that's okay, because new software has bugs and in some of my other use cases "hey it's a lot better than Jack". What I'm not going to do is carry a grudge against the maintainer for decades? I've been using Linux since Slackware installed from a pile of floppy disks. I'm extremely happy with systemd (desktop and server) and view it as one of the most important UX advancements ever made in the Linux sysadmin space. It replaced a smorgasbord of broken nonsense with a unified and thoughtful system that is objectively superior to what it replaced. I suspect a lot of the extreme reaction to systemd is not just resistance to change, but based on an emotional attachment to the rag-tag heterogeneity it made obsolete.

UI_at_80x24 4y ago

On my laptop, systemd is awesome; I love it. Everything works together nicely. On my servers, systemd gets in my way, tries to do too many things, and gets in my way more then it helps. On a laptop things are much more dynamic. From sleep/hibernation/wifi-LAN-wifi (+/- VPN) switching/etc.... these fiddly bits were much harder to manage on Linux for DECADES then they are now. The reboot interval on laptops is huge compared to servers. An init system (plus all the extra plumbing) work well together. On servers however; I HATE systemd. For logging, networking (and DNS) alone systemd wastes so much more of my time and gets in my way. I think the need for an 'improved' init system was always a red herring. I've never had a service race-condition, or other conflict that didn't take more then 10 minutes to fix in the 30 years I've managed *nix servers. There was one time where I was stumped why my VPN server kept failing to start at boot but came up fine if I restarted manually. My dyslexic ass inverted the script number (ie. 13 instead of 31 or something like that). That was just a face-palm embarrassment.

lrvick 4y ago
Systemd should never be used on a server. Or any other desktop init system for that matter. Production systems should never be changed or administered in place, only replaced. Servers should be immutable appliances. They do not need a package manager, or systemd, or ssh, or even a shell. Such things are developer tools and only belong in development environments like workstations. A production filesystem should contain a kernel, an init binary, and either a container runtime or a static binary of your target application. At most a production init binary just needs to setup virtual filesystems and be a reaper for a target application binary.
- effie 4y ago
  > Production systems should never be changed or administered in place, only replaced. Servers should be immutable appliances. They do not need a package manager, or systemd, or ssh, or even a shell. Such things are developer tools and only belong in development environments like workstations. That is a very restrictive work methodology (unikernels,exokernels). Although interesting and certainly useful in some cases (high security, rare updates), Bryan Cantrill was partially right on this - in the real world, we often need to debug stuff running in production and support paying customers who require that. Your idea of "production systems" and "servers" seems very specific and the "should" statements are often not true in practice. Developer tools definitely belong on the server too, you need them to determine how to build your stack binaries in the best way for the OS and HW architecture there and keep them updated and secure.

excsn 4y ago

Hehe, I remember some people complaining about it. I never could hate SystemD once introduced to it as an infrastructure engineer. The difference was night and day in Debian (from wheezy to jessie). Setting common sig handlers, restart on exit, etc. are just one-liners with unit files. In the previous one, SysV, it was an annoying incantation especially if you were a newbie, like me at the time, or product engineer who was dabbling. You could easily screw it up. Some non infra engineers cursed the SysV files and loved the SystemD unit files. Now I use dynamic user and the other security features in my unit files and wonder how many lines it would have taken to do that in SysV, so the complaints are laughable at this point.

traverseda 4y ago

Less hated ad time goes on. I still think it's architecturally stupid (look at openrc for something that accomplishes similar goals but better), but it's been a while since it's broken anything terribly for me, or introduced any terrible security vulnerability. It's not great, but it's not actively hurting.