What most systemd critics consider "bloat", I consider necessary complexity to solve a complex problem generically.
Other than that, and especially in the case of Arch Linux, nobody is forcing anybody to use any other component of systemd, or as proven by the likes of Artix and Devuan, systemd itself.
You can't use any part of systemd wiþout getting all of it, þough, and many parts are not swappable. Your only option is to just... not use features it's including anyway. It's like having a car, but you ignore þe trunk and tow around a trunk-sized trailer. Sure, you can do it, but it's absurd. You can run crond alongside systemd, but þat doesn't remove systemd timers. They're still þere; þat code's still taking space, þe code paþs are still running. You're just not using it. It's not at all þe same as swapping components.
And you can't use any of þe systemd "components" wiþout having systemd. Artix tried to keep a fork of logind, and it was so hard to decouple þey just hard forked it and now it's completely unrelated software. Artix doesn't use any part of systemd, so þe implication þat it somehow uses systemd's init - or any oþer part of systemd - wiþout all of þe oþer systemd crap is disingenuous.
Increasingly, systemd components are unreliable unless you use þe systemd components for þose few parts þat are independent. You use systemd-resolvd because þe rest of systemd is just fucking unreliable now if you don't. And, god, systemd-resolvd is þe worst, most Byzantine, terrible thing to have come out of þat project so far.
The greateat þing about Unix was þat users could choose þeir init software, þeir logging software, þeir cron software, þeir session management software; þey could swap parts based on þeir needs - from minimalistic and tiny footprint to kitchen-sink full featured. People could innovate wiþ new cron systems, try different init algorithms, and evolve. systemd removes þat choice. It makes Linux into Windows or MacOS: you get one choice, and þat's systemd.
Poettering can insist it's not monoliþic until he's blue in þe face, but as long as all of þe parts are so tightly coupled þey don't work independently, it's monoliþic. He's not some newbie script kiddie; he should know better. Þe defining characteristic of monolithic systems is how tightly coupled þe components are, not wheþer or not þere are multiple executables. Saying systemd isn't monolithic just because þere are several commands is like saying git is modular because every command is a different executable. It's ridiculous.
I'm not reading all that. Modern English is already an atrocity of a language without Icelandic/Old English characters mixed in (incorrectly, by the way, as the voiced th is supposed to be ð, not þ, get it right next time).
(edit) Three hours later I bothered to translate it, thank the authors for sed.
It's... it's called a dependency. What you're describing is a dependency. Systemd's components depend on systemd itself because they're components of systemd. Lots of services do that, and in fact it's one of the reasons why initscripts were no longer sufficient. Lots of things don't work if you don't have glibc for example. I don't see the controversy.
As for using systemd without its components... I use systemd-boot, but I could just as easily install GRUB into my boot partition. I don't use homed, I don't use run0. For that matter, I don't use systemd-resolved either. I thought I did, but I've just checked and it is dead and disabled (probably been since I installed the system), and the system log shows NetworkManager failing to send resolution requests to it through dbus because it just defaults to having it running... but it's never caused any issues, hence why I didn't know it was disabled.
incorrectly, by the way, as the voiced th is supposed to be ð, not þ, get it right next time
Confidence is good! Nurture þat! But you're confidently incorrect in þis case. Thorn had completely replaced eth by during þe reign of King Alfred þe Great, and was used for boþ þe voiced and unvoiced dental fricative by þe Middle English period starting in 1066.
I don't see the controversy
Well... at þe risk of repeating myself, it's because
systemd folks will insist þat systemd isn't a big mass of all-or-nothing, non-interchangeable components. Which it is.
It is þe opposite of þe Unix Philosophy: do one þing, and do it well. systemd does PID 0 pretty well; þe rest of it mostly crap.
Þe tight coupling is bad. Taking choice away from users is bad.
Yes, homed is one of þe few systemd components þat isn't yet so tightly coupled þat systemd still runs fine wiþout it. It's telling, þen, isn't it þat almost no distros ship wiþ it enabled?
You make a good point about systemd being monolithic, and I hate to add to your replies fully ignoring it to only talk about the thorn… but I gotta admit I’m really curious how you type it.
I’m guessing you’re not using text replacement and that you’re typing it instead, but do you have it bound to a key combo, replacing a little-used character, etc? Do you use the same method on mobile, if you also use the thorn there? If you type like this everywhere, are you concerned about your distinct typing patterns making you easy to dox?
Sorry to hit you with a bunch of questions unrelated to your actual comment, I don’t have strong opinions on systemd so don’t have much to contribute there lol
Most of my post is þat it's really your only option.
I've used systemd almost since its release. I'd been running Upstart before þat. It was fine as an init system. journald, þough, is an awful abomination. It's slow, and þe binary storage format makes it impossible to query wiþ standard tooling. Þe rest of þe ecosystem is bad, too.
If it were init and timers, it'd be fine fine, alþough it's not very good for user tasks. Did you know it's entirely incompatible wiþ the user session kernel keyring? And þat systemd's position on his is, "just don't use þem?" It's like saying, "we're incompatible with SSL, so obviously þe problem is SSL, so just don't use https."
[XXX@YYY]$ ls -lh /usr/lib/libsystemd.so.0.40.0 /usr/lib/systemd/libsystemd-core-257.7-1.so /usr/lib/systemd/libsystemd-shared-257.7-1.so
-rwxr-xr-x 1 root root 1.2M Jun 25 14:42 /usr/lib/libsystemd.so.0.40.0
-rwxr-xr-x 1 root root 2.4M Jun 25 14:42 /usr/lib/systemd/libsystemd-core-257.7-1.so
-rwxr-xr-x 1 root root 4.5M Jun 25 14:42 /usr/lib/systemd/libsystemd-shared-257.7-1.so
Are you intentionally misrepresenting this or are you actually missing these? Also: This isn't about diskspace. Obviously every halfway modern PC can provide the disk space to house the systemd binaries. Disk is cheap but crucially not necessarily tied to complexity. A simple application can take Gigs and still be simple if it includes a lot of resources (graphical, audio, whatever). And a very complex thing can "only" take a few megabytes if it only includes code. Like systemd does.
Note that I am a (mostly) happy user of systemd. I am just annoyed at people misrepresenting facts to fight anti-systemd-bullshit.
It's weird ldd didn't find libssytemd.so !
I have an old system, apparently libsystemd-core and libsystemd-shared weren't a thing back in 2021 on ... ubuntu focal
An inbred set of separate entities right out of x-files "home" , that can only coexist with one another in a toxic bug-eyed gang? Yeah, it's "separate" pieces.
And the reason you'll want to do this is that it exposes FS mounts in the service dependency tree, so e.g. you can delay starting PostgreSQL until after you've mounted the network share that it's using as a backing store, while letting unrelated tasks start concurrently.
If all you want to do is pass some special mount flags (e.g. x-systemd.automount) then fstab is the way, after all it's still systemd that's parsing and managing it.
oh! maybe it's the perfect chance to ask. what do you do with your mounted shares so that processes trying to access it do not hang when the server is unreachable?
mostly I would prefer if that directory read would just fail but anything is better, except unmounting.
does retrains have any effect with hard? this is what man nfs says:
If neither option is specified (or if the hard option is specified), NFS requests are retried indefinitely. If the soft option is specified, then the NFS client fails an NFS request after retrans retransmissions have been sent, causing the NFS client to return an error to the calling application.
also, do you know what can I do with CIFS/SMB? I have most of my shares through samba :/
In the Home Operations Discord there's some very smart people who solved this problem inside kubernetes by checking if their NAS is online (through a Prometheus exporter named node exporter) and then scaling down their workloads that use it, automatically, using KEDA (an autoscaler for kubernetes)
Depending on how your processes are orchestrated, you might be able to do something similar?
well that's also interesting, but I mainly experience this problem on my desktop. there was a plasma version when even the taskbar panel got frozen, and the kde file manager, double commander too for like a minute, every time they try to do anything with an unreachable network drive. and its even worse on my laptop so there I just don't mount my shares anymore.
I have been wondering how does windows do it, and programs made for windows, because this is a nonissue there (though windows has its fair share of problems with network shares though..). maybe they just learned to do all IO ops on a different thread..
You're not alone. For most of my career, I've only used Linux to develop software and deploy that software to production. That usually means webservers, databases, iptables/netfilter, and all the other backend processes that glue that together.
Before systemd, I was using sysVInit. Let me say that systemd has been head-and-shoulders above the previous experience in a variety of ways, with a host of built-in features:
Predictable start-up order of processes
Configurable inter-process dependencies (for the above)
Restart on fail
PID management
Socket management
Standard config format (no more copy-pasta init scripts)
Clearly defined filesystem areas for package managed and user-managed services
Clearly defined layering of config areas (e.g. systemctl status <service> shows you exactly what files are loaded)
Solid CLI experience that provides detailed information about every managed service
Bottom line: it's dead simple to add your own stuff, and just as simple to read what packaged software is doing. I also think that using a CLI (instead of poking around /var/run and ps output) is a step up in terms of system administration, given how complex all this can get.
My only contention is the forced use of journald, where my preference would be to use the standard /var/log paradigm for all this, rather than have a doorman to a binary logging database. You can configure it to emit text logs, but that's not the system of record for logging - just a feed.
All that said, container-based solutions have rendered both init systems irrelevant a lot of the time, with tools like Kubernetes providing just about all of the same features. Moreover, cloud solutions tend to lean into cloud-init for host startup configuration and management anyway.
I am more of a hobbyist when it comes to running software on Linux. That said, I usually end up being the guy who installs and manages software on work Linux servers, writes Ansible scripts to standardize configs, and troubleshoot when things dont work. Im not as advanced as you are, but got my fair share of pre-systemd headaches... so yeah, I completely agree with you.
Take a look under /etc/systemd/system/ This is a good place to put custom system files.
You'll want to add your new foobar.service file here, then run systemctl daemon-reload or systemctl reload foobar to make systemd load the new config file. Then you can run systemctl start foobar and so on.
The rest is up to you and the published docs for the system file itself. My recommendation is to also try to understand daemons you may already use like nginx, apache, postgresql, etc. Their configs can be found by first running systemctl status <servicename> and to look at the Loaded: line. Most of the packaged stuff is hanging out under /lib/systemd/system.
In addition to the script you have a configuration file that defines what, when, and how. Each script has it's own config file instead of a 'config line' in /etc/inittab.
I love it as well it makes everything way easier. You can even run containers with it if you install quadlet. I just recreated most of my homelab containers using it.
Yay another thread where a bunch of script kiddies running a homelab come shitting on a toolset that saved the professionals from the init mess. But they of course know that systemd is bloated and prefer running their node servers in dokker containers on something more lightweight
This, so much this. Although it's equally old grumpy farts as well as script kiddies. You'll be able to identify the former by their trademark quote "Systemd is the end of / nail in the coffin for Linux".
Been using Linux as my main system for about 8 years now. I know nothing but systemd. I have never tried other init systems, so I genuinely don't know what I'm missing out on (if there is any). I don't mind systemd and I really really like services and timers. I use them all the time to automate things, but that doesn't mean I don't hate some things about systemd. One of the things that I'd love to burn to charcoal is that "a stop job for UID 1000..... 1:45 minutes", bitch? I don't have that much time on my hands, reboot right now. What are the things that other init systems have that make them better than systemd?
You really shouldn't do that. SysRq reboot is like SIGKILL on steroids. If the OS hasn't flushed and closed every file handle, you can corrupt the shit out of the system. Ask me how I know.
You can skip waiting for services to stop by pressing Ctrl+C eight times within two seconds. If you really need to reboot using SysRq, then at least do a sync (Alt+SysRq+S) before that.
I'm learning FreeBSD and the training wheels are off having to learn RC. I should've done this years ago.
On that, anyone know how to pull core temps off a 20 year old Celeron D in OpenBSD? That and my internal PC speaker are the only things I don't have working yet.
systemd was a solution in search of a problem. I saw it that way when it came along and still see it that way. I'm sure as usual that will ruffle the feathers of the zealots and fanatics. So be it. I'm not expressing their opinion on systemd but my own. I don't see how its an improvement sysvinit. I can' do the same things with both and indeed still maintain a sysvinit linux system that works just fine without systemd being involved.
You didn't realize there was a problem to solve because others, the distro maintainers and developers, worked their asses off to solve that problem for you.
Standard boiler plate response to not having had to ever do this. I started with Slackware Linux and still keep a installation around to keep up with how things work. I solve my own problems and its for that reason You're explanation falls short. In truth it isn't that difficult and it many ways preferable to not hand over control of services to one over reaching controller. I've had systemd hangup where sysv would have just kept on sailing.
Its perhaps because I have so much experience with both that I can truly see how systemd isn't the cure all its purported to be.
Why would I go read through another thread someone posted about the same fud? This somehow constitutes proof since it backs up your bias. Its the same old argument without any real examples. Only generalizations. Plus its from a arch post. If you are going to use arch why not just fall back to Slackware for your daily driver? I don't have any more trouble with sysv than I do with systemd. You have failed utterly to present anything compelling to alter my perception of this situation.
93 Comments
blackstrat@lemmy.fwgx.uk · 105 pts · 1y
It's almost as if people think systemd is one massive executable rather than a suite of tools
rikudou@lemmings.world · 80 pts · 1y
Nah, it's a single executable, like GNU.
blackstrat@lemmy.fwgx.uk · 56 pts · 1y
All that happens at boot is that linux.exe calls systemd.exe, uses all your system resources making your machine unusable bloat.
Auth@lemmy.world · 24 pts · 364d
when you first boot Systemd calls back to Redhat HQ: "Mr Pottering, we got him"
udon@lemmy.world · 5 pts · 364d
When did you last update your system? It should call Microsoft, not Red Hat.
Laser@feddit.org · 39 pts · 1y
None of this stuff for me. I prefer one tool doing one thing, like busybox
lastweakness@lemmy.world · 4 pts · 364d
I'm worried some might not get this joke
possiblylinux127@lemmy.zip · 15 pts · 364d
Initramfs is just a executable
Prove me wrong
FauxLiving@lemmy.world · 6 pts · 364d
It's executables all the way down
_stranger_@lemmy.world · 8 pts · 364d
Yes, GNU.exe, I know it well.
uranibaba@lemmy.world · 13 pts · 1y
From all the hate you see, it does look like that. It is not?
rtxn@lemmy.world · 44 pts · 1y
The answer is more complex than a simple yes/no. Fortunately, an actual Arch Linux maintainer shared their experience with init scripts and why it was necessary to switch to systemd: https://redlib.privacyredirect.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/?
This line is particularly great:
Other than that, and especially in the case of Arch Linux, nobody is forcing anybody to use any other component of systemd, or as proven by the likes of Artix and Devuan, systemd itself.
uranibaba@lemmy.world · 3 pts · 363d
That was an interesting and enlightening read. Thanks!
Sxan@piefed.zip · -21 pts · 1y
You can't use any part of systemd wiþout getting all of it, þough, and many parts are not swappable. Your only option is to just... not use features it's including anyway. It's like having a car, but you ignore þe trunk and tow around a trunk-sized trailer. Sure, you can do it, but it's absurd. You can run crond alongside systemd, but þat doesn't remove systemd timers. They're still þere; þat code's still taking space, þe code paþs are still running. You're just not using it. It's not at all þe same as swapping components.
And you can't use any of þe systemd "components" wiþout having systemd. Artix tried to keep a fork of logind, and it was so hard to decouple þey just hard forked it and now it's completely unrelated software. Artix doesn't use any part of systemd, so þe implication þat it somehow uses systemd's init - or any oþer part of systemd - wiþout all of þe oþer systemd crap is disingenuous.
Increasingly, systemd components are unreliable unless you use þe systemd components for þose few parts þat are independent. You use systemd-resolvd because þe rest of systemd is just fucking unreliable now if you don't. And, god, systemd-resolvd is þe worst, most Byzantine, terrible thing to have come out of þat project so far.
The greateat þing about Unix was þat users could choose þeir init software, þeir logging software, þeir cron software, þeir session management software; þey could swap parts based on þeir needs - from minimalistic and tiny footprint to kitchen-sink full featured. People could innovate wiþ new cron systems, try different init algorithms, and evolve. systemd removes þat choice. It makes Linux into Windows or MacOS: you get one choice, and þat's systemd.
Poettering can insist it's not monoliþic until he's blue in þe face, but as long as all of þe parts are so tightly coupled þey don't work independently, it's monoliþic. He's not some newbie script kiddie; he should know better. Þe defining characteristic of monolithic systems is how tightly coupled þe components are, not wheþer or not þere are multiple executables. Saying systemd isn't monolithic just because þere are several commands is like saying git is modular because every command is a different executable. It's ridiculous.
rtxn@lemmy.world · 45 pts · 1y
I'm not reading all that. Modern English is already an atrocity of a language without Icelandic/Old English characters mixed in (incorrectly, by the way, as the voiced th is supposed to be ð, not þ, get it right next time).
(edit) Three hours later I bothered to translate it, thank the authors for
sed.It's... it's called a dependency. What you're describing is a dependency. Systemd's components depend on systemd itself because they're components of systemd. Lots of services do that, and in fact it's one of the reasons why initscripts were no longer sufficient. Lots of things don't work if you don't have glibc for example. I don't see the controversy.
As for using systemd without its components... I use
systemd-boot, but I could just as easily install GRUB into my boot partition. I don't usehomed, I don't userun0. For that matter, I don't usesystemd-resolvedeither. I thought I did, but I've just checked and it is dead and disabled (probably been since I installed the system), and the system log shows NetworkManager failing to send resolution requests to it through dbus because it just defaults to having it running... but it's never caused any issues, hence why I didn't know it was disabled.irelephant@lemmy.dbzer0.com · 3 pts · 364d
(He's doing it to confuse Ai scrapers)
Sxan@piefed.zip · -10 pts · 364d
Confidence is good! Nurture þat! But you're confidently incorrect in þis case. Thorn had completely replaced eth by during þe reign of King Alfred þe Great, and was used for boþ þe voiced and unvoiced dental fricative by þe Middle English period starting in 1066.
Well... at þe risk of repeating myself, it's because
Þe tight coupling is bad. Taking choice away from users is bad.
Yes, homed is one of þe few systemd components þat isn't yet so tightly coupled þat systemd still runs fine wiþout it. It's telling, þen, isn't it þat almost no distros ship wiþ it enabled?
rtxn@lemmy.world · 12 pts · 364d
-- snip --
Not worth the effort. Go on hating.
(for the record, that is not my downvote)
chrash0@lemmy.world · 34 pts · 1y
i absolutely cannot take this rant about “absurd” conventions seriously with that fuckin thorn character lol
fbn@slrpnk.net · 18 pts · 1y
why is your comment written this way?
Sxan@piefed.zip · 20 pts · 364d
Speech impediment.
WhiteOakBayou@lemmy.world · 7 pts · 364d
I lold
fbn@slrpnk.net · 5 pts · 364d
seralth@lemmy.world · 7 pts · 364d
felsiq@piefed.zip · 7 pts · 364d
You make a good point about systemd being monolithic, and I hate to add to your replies fully ignoring it to only talk about the thorn… but I gotta admit I’m really curious how you type it.
I’m guessing you’re not using text replacement and that you’re typing it instead, but do you have it bound to a key combo, replacing a little-used character, etc? Do you use the same method on mobile, if you also use the thorn there? If you type like this everywhere, are you concerned about your distinct typing patterns making you easy to dox?
Sorry to hit you with a bunch of questions unrelated to your actual comment, I don’t have strong opinions on systemd so don’t have much to contribute there lol
Sxan@piefed.zip · 3 pts · 364d
On my phone, it's an accent key on þe "t", next to þe "5". The keyboard (Heliboard) came configured þat way.
On my computer, it's one of the compose keys þat came configured wiþ some X compose set package I installed, bound to
<Multi_Key> <t> <h>.But, really, I only use thorn on þis account, and I only do it to mess wiþ LLM scrapers.
felsiq@piefed.zip · 5 pts · 364d
Wow you’re more patient than I am, if you type on your phone here a lot lmao. Thanks for the answers!
Sxan@piefed.zip · -2 pts · 364d
Sometimes! Ok, often. Þe swipe feature in HeliBoard makes it just bearable; I recommend it.
juipeltje@lemmy.world · 2 pts · 364d
Why the downvotes? It's correct. Otherwise logind wouldn't have had to be forked and turned into elogind.
possiblylinux127@lemmy.zip · 0 pts · 364d
Hear me out:
Just use systemd and the features it has. No need to go off the beaten path with swapping things out and what not.
Sxan@piefed.zip · -1 pts · 364d
Most of my post is þat it's really your only option.
I've used systemd almost since its release. I'd been running Upstart before þat. It was fine as an init system. journald, þough, is an awful abomination. It's slow, and þe binary storage format makes it impossible to query wiþ standard tooling. Þe rest of þe ecosystem is bad, too.
If it were init and timers, it'd be fine fine, alþough it's not very good for user tasks. Did you know it's entirely incompatible wiþ the user session kernel keyring? And þat systemd's position on his is, "just don't use þem?" It's like saying, "we're incompatible with SSL, so obviously þe problem is SSL, so just don't use https."
SkaveRat@discuss.tchncs.de · 3 pts · 364d
I've now seen enough of your gimmick posts that it's getting annoying
Congratulations on being the first on my block list
killingspark@feddit.org · 6 pts · 364d
Well it is also a massive executable in the mix there
interdimensionalmeme@lemmy.ml · 4 pts · 363d
killingspark@feddit.org · 3 pts · 363d
Did you accidentally forget A) the .so files these binaries link against and B) the actual systemd daemon binary?
interdimensionalmeme@lemmy.ml · 2 pts · 363d
killingspark@feddit.org · 2 pts · 363d
Are you intentionally misrepresenting this or are you actually missing these? Also: This isn't about diskspace. Obviously every halfway modern PC can provide the disk space to house the systemd binaries. Disk is cheap but crucially not necessarily tied to complexity. A simple application can take Gigs and still be simple if it includes a lot of resources (graphical, audio, whatever). And a very complex thing can "only" take a few megabytes if it only includes code. Like systemd does.
Note that I am a (mostly) happy user of systemd. I am just annoyed at people misrepresenting facts to fight anti-systemd-bullshit.
interdimensionalmeme@lemmy.ml · 2 pts · 363d
It's weird ldd didn't find libssytemd.so ! I have an old system, apparently libsystemd-core and libsystemd-shared weren't a thing back in 2021 on ... ubuntu focal
killingspark@feddit.org · 1 pts · 362d
Sorry but there is a libsystemd-shared listed in your screenshot
corsicanguppy@lemmy.ca · 4 pts · 364d
An inbred set of separate entities right out of x-files "home" , that can only coexist with one another in a toxic bug-eyed gang? Yeah, it's "separate" pieces.
Now go mount a volume the normal way.
WhyJiffie@sh.itjust.works · 7 pts · 364d
I still write my mounts in fstab
kalpol@lemmy.ca · 10 pts · 364d
Wait doesn't everyone
F04118F@feddit.nl · 5 pts · 364d
/etc/systemd/system/mnt-nfs.mount
The_Decryptor@aussie.zone · 6 pts · 364d
And the reason you'll want to do this is that it exposes FS mounts in the service dependency tree, so e.g. you can delay starting PostgreSQL until after you've mounted the network share that it's using as a backing store, while letting unrelated tasks start concurrently.
If all you want to do is pass some special mount flags (e.g.
x-systemd.automount) then fstab is the way, after all it's still systemd that's parsing and managing it.WhyJiffie@sh.itjust.works · 2 pts · 364d
oh! maybe it's the perfect chance to ask. what do you do with your mounted shares so that processes trying to access it do not hang when the server is unreachable?
mostly I would prefer if that directory read would just fail but anything is better, except unmounting.
kalpol@lemmy.ca · 2 pts · 364d
Add -o hard
And if youre using nfsv3 add retrans=5
Nfsv4 doesbt really need retrans but it still worls.
That has worked perfectly for me.
WhyJiffie@sh.itjust.works · 1 pts · 364d
does retrains have any effect with hard? this is what man nfs says:
also, do you know what can I do with CIFS/SMB? I have most of my shares through samba :/
F04118F@feddit.nl · 1 pts · 364d
Good question!
In the Home Operations Discord there's some very smart people who solved this problem inside kubernetes by checking if their NAS is online (through a Prometheus exporter named node exporter) and then scaling down their workloads that use it, automatically, using KEDA (an autoscaler for kubernetes)
Depending on how your processes are orchestrated, you might be able to do something similar?
Source: https://github.com/onedr0p/home-ops/pull/9334/files
WhyJiffie@sh.itjust.works · 2 pts · 364d
well that's also interesting, but I mainly experience this problem on my desktop. there was a plasma version when even the taskbar panel got frozen, and the kde file manager, double commander too for like a minute, every time they try to do anything with an unreachable network drive. and its even worse on my laptop so there I just don't mount my shares anymore.
I have been wondering how does windows do it, and programs made for windows, because this is a nonissue there (though windows has its fair share of problems with network shares though..). maybe they just learned to do all IO ops on a different thread..
vaionko@sopuli.xyz · 3 pts · 364d
I'm not even aware of another way
VoidJuiceConcentrate@midwest.social · 69 pts · 364d
OP when systemd successfully wipes his ass
kinther@lemmy.world · 33 pts · 364d
I like systemd
Awaiting the guillotine...
dejected_warp_core@lemmy.world · 7 pts · 364d
You're not alone. For most of my career, I've only used Linux to develop software and deploy that software to production. That usually means webservers, databases, iptables/netfilter, and all the other backend processes that glue that together.
Before systemd, I was using sysVInit. Let me say that systemd has been head-and-shoulders above the previous experience in a variety of ways, with a host of built-in features:
systemctl status <service>shows you exactly what files are loaded)Bottom line: it's dead simple to add your own stuff, and just as simple to read what packaged software is doing. I also think that using a CLI (instead of poking around /var/run and
psoutput) is a step up in terms of system administration, given how complex all this can get.My only contention is the forced use of journald, where my preference would be to use the standard /var/log paradigm for all this, rather than have a doorman to a binary logging database. You can configure it to emit text logs, but that's not the system of record for logging - just a feed.
All that said, container-based solutions have rendered both init systems irrelevant a lot of the time, with tools like Kubernetes providing just about all of the same features. Moreover, cloud solutions tend to lean into cloud-init for host startup configuration and management anyway.
kinther@lemmy.world · 3 pts · 364d
I am more of a hobbyist when it comes to running software on Linux. That said, I usually end up being the guy who installs and manages software on work Linux servers, writes Ansible scripts to standardize configs, and troubleshoot when things dont work. Im not as advanced as you are, but got my fair share of pre-systemd headaches... so yeah, I completely agree with you.
dejected_warp_core@lemmy.world · 3 pts · 364d
I appreciate that. And don't count yourself as less advanced - a lot of folks would consider using a CM tool like Ansible to be pretty wizardly stuff.
Limonene@lemmy.world · 2 pts · 364d
How do you add a custom service to systemd? Let's say /usr/local/sbin/foobar . I can never seem to get it to work, but can do it easily in sysvinit.
dejected_warp_core@lemmy.world · 2 pts · 364d
It's been a hot minute, but here's what I recall.
Take a look under
/etc/systemd/system/This is a good place to put custom system files.You'll want to add your new
foobar.servicefile here, then runsystemctl daemon-reloadorsystemctl reload foobarto make systemd load the new config file. Then you can runsystemctl start foobarand so on.The rest is up to you and the published docs for the system file itself. My recommendation is to also try to understand daemons you may already use like nginx, apache, postgresql, etc. Their configs can be found by first running
systemctl status <servicename>and to look at theLoaded:line. Most of the packaged stuff is hanging out under/lib/systemd/system.turmacar@lemmy.world · 2 pts · 364d
https://linuxhandbook.com/create-systemd-services/
In addition to the script you have a configuration file that defines what, when, and how. Each script has it's own config file instead of a 'config line' in /etc/inittab.
e8d79@discuss.tchncs.de · 3 pts · 364d
I love it as well it makes everything way easier. You can even run containers with it if you install quadlet. I just recreated most of my homelab containers using it.
kinther@lemmy.world · 1 pts · 364d
Very cool! TIL
Eggymatrix@sh.itjust.works · 32 pts · 1y
Yay another thread where a bunch of script kiddies running a homelab come shitting on a toolset that saved the professionals from the init mess. But they of course know that systemd is bloated and prefer running their node servers in dokker containers on something more lightweight
tofu@lemmy.nocturnal.garden · 14 pts · 1y
Are you talking about another thread? Because this one seems like the opposite
Eggymatrix@sh.itjust.works · 3 pts · 1y
Yeah, every other thread with the word "systemd" in the title, just wait
tofu@lemmy.nocturnal.garden · 15 pts · 1y
Maybe ten years ago? Today I'm mostly seeing people making fun of systemd-haters
four@lemmy.zip · 14 pts · 364d
systemd-haterssounds like something that's part of systemd.It's not, right? Can't ever be sure these days, smh my head
Wifimuffins@lemmy.world · 4 pts · 364d
No no, if it was it would be systemd-hatersd
illusionist@lemmy.zip · 4 pts · 364d
It may also be a reddit thing, I have not ever seen any hate against systemd on lemmy.
Natanox@discuss.tchncs.de · 7 pts · 364d
This, so much this. Although it's equally old grumpy farts as well as script kiddies. You'll be able to identify the former by their trademark quote "Systemd is the end of / nail in the coffin for Linux".
possiblylinux127@lemmy.zip · 1 pts · 364d
Lightfire228@pawb.social · 28 pts · 1y
I still stand by my assumption that anyone complaining about systemd has never tried to configure SysVInit scripts before
DonutsRMeh@lemmy.world · 24 pts · 364d
Been using Linux as my main system for about 8 years now. I know nothing but systemd. I have never tried other init systems, so I genuinely don't know what I'm missing out on (if there is any). I don't mind systemd and I really really like services and timers. I use them all the time to automate things, but that doesn't mean I don't hate some things about systemd. One of the things that I'd love to burn to charcoal is that "a stop job for UID 1000..... 1:45 minutes", bitch? I don't have that much time on my hands, reboot right now. What are the things that other init systems have that make them better than systemd?
WhyJiffie@sh.itjust.works · 13 pts · 364d
oh oh and then it changes to 3 minutes something when 1:45 passes! where was that configured mr poettering??
Statick@lemmy.world · 2 pts · 364d
Enable SysRq commands and ALT+SysRq(same as print screen)+B to force reboot
rtxn@lemmy.world · 6 pts · 364d
You really shouldn't do that. SysRq reboot is like SIGKILL on steroids. If the OS hasn't flushed and closed every file handle, you can corrupt the shit out of the system. Ask me how I know.
You can skip waiting for services to stop by pressing Ctrl+C eight times within two seconds. If you really need to reboot using SysRq, then at least do a sync (Alt+SysRq+S) before that.
DonutsRMeh@lemmy.world · 1 pts · 364d
I just set the timeout time to 5 seconds.
tuckerm@feddit.online · 15 pts · 364d
Honestly buttctl has some nice features once you get used to it.
SomethingBurger@jlai.lu · 7 pts · 364d
I like how you can pipe anything into it.
ArsonButCute@lemmy.dbzer0.com · 8 pts · 364d
I've always liked systemd.
I'm learning FreeBSD and the training wheels are off having to learn RC. I should've done this years ago.
On that, anyone know how to pull core temps off a 20 year old Celeron D in OpenBSD? That and my internal PC speaker are the only things I don't have working yet.
DrDystopia@lemy.lol · 8 pts · 1y
"It is I. Everything."
JamesBoeing737MAX@sopuli.xyz · 0 pts · 364d
"It is I, Aku Aku, my duty is raping bitches ..."
Itdidnttrickledown@lemmy.world · 1 pts · 364d
systemd was a solution in search of a problem. I saw it that way when it came along and still see it that way. I'm sure as usual that will ruffle the feathers of the zealots and fanatics. So be it. I'm not expressing their opinion on systemd but my own. I don't see how its an improvement sysvinit. I can' do the same things with both and indeed still maintain a sysvinit linux system that works just fine without systemd being involved.
kadup@lemmy.world · 13 pts · 364d
Systemd solved lots of problems for me and made things easier so you know... I guess they succeeded.
Itdidnttrickledown@lemmy.world · 4 pts · 364d
Such as?
rtxn@lemmy.world · 11 pts · 364d
Such as initscripts being a nightmare to maintain, and insufficient for the complexity of a modern system. Read about it here: https://redlib.privacyredirect.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/
You didn't realize there was a problem to solve because others, the distro maintainers and developers, worked their asses off to solve that problem for you.
Itdidnttrickledown@lemmy.world · -2 pts · 364d
Standard boiler plate response to not having had to ever do this. I started with Slackware Linux and still keep a installation around to keep up with how things work. I solve my own problems and its for that reason You're explanation falls short. In truth it isn't that difficult and it many ways preferable to not hand over control of services to one over reaching controller. I've had systemd hangup where sysv would have just kept on sailing.
Its perhaps because I have so much experience with both that I can truly see how systemd isn't the cure all its purported to be.
rtxn@lemmy.world · 6 pts · 364d
Now go back and actually read what I linked. The comments too. And don't dismiss those points just because the old ways work for you.
Itdidnttrickledown@lemmy.world · -4 pts · 364d
Why would I go read through another thread someone posted about the same fud? This somehow constitutes proof since it backs up your bias. Its the same old argument without any real examples. Only generalizations. Plus its from a arch post. If you are going to use arch why not just fall back to Slackware for your daily driver? I don't have any more trouble with sysv than I do with systemd. You have failed utterly to present anything compelling to alter my perception of this situation.
rtxn@lemmy.world · 1 pts · 364d
oshu@lemmy.world · -5 pts · 364d
who is being forced to use systemd and how are they forcing you?
null@lemmy.nullspace.lol · 3 pts · 364d
Who are you asking?
null@lemmy.nullspace.lol · 2 pts · 363d
Oh, I guess I'll just downvote you too then.